5

I'm brand new to multi-threaded processing, so please forgive me if I butcher terms or miss something obvious.

The code below doesn't offer any time advantage over different code that calls the same two functions one after the other.


import time
import threading

start_time = time.clock()

def fibonacci(nth): #can be ignored
    first = 0
    second = 1
    for i in range(nth):
        third = first + second
        first = second
        second = third
    print "Fibonacci number", i + 1, "is", len(str(first)), "digits long"

def collatz(collatz_max): #can be ignored
    for n in range(collatz_max):
        n = n + 1 #avoid entering 0
        solution = []
        solution.append(n)
        while n != 1:
            if n % 2 == 0:
                n = n / 2
            else:
                n = (n*3) + 1
            solution.append(n)
    print "Path for Collatz number", collatz_max, "is", solution

def scripts():
    thread_fibonacci = threading.Thread(target=fibonacci, args = (800000,))
    thread_collatz = threading.Thread(target=collatz, args = (400000,))

    thread_fibonacci.start()
    thread_collatz.start()

    return thread_fibonacci, thread_collatz

all_scripts = scripts()

#wait until both threads are finished
for script in all_scripts:
    script.join()

print time.clock() - start_time, "seconds"

What do I need to do to make the threads simultaneous? Does GIL mean concurrency can only be achieved through separate processes? If so, what is the point of multithreading?

Using Python 2.7.5 on Windows 8.1, quad-core processor. Any help would be appreciated.

Jim V
  • 1,131
  • 12
  • 22
  • 2
    You may want to check this answer out: http://stackoverflow.com/a/1294402/58129 – Anthony Kong Oct 27 '13 at 03:16
  • 7
    Use `multiprocessing` instead of `threading` to get around the GIL limitation. – Blender Oct 27 '13 at 03:20
  • What Blender said. See this question for more details / examples -- http://stackoverflow.com/questions/17424569/python-threading-vs-multiprocessing-in-linux – DreadPirateShawn Oct 27 '13 at 03:22
  • 1
    Also, this answer outlines pros & cons of threads vs processes: http://stackoverflow.com/questions/3044580/multiprocessing-vs-threading-python/3046201#3046201 – DreadPirateShawn Oct 27 '13 at 03:24
  • I understand processes run in an separate memory space, but is there a way for processes to exchange data with the main thread of execution? Also, are these processes like the ones seen in Windows Task Manager? (sorry if that's a dumb question) – Jim V Oct 27 '13 at 04:03

1 Answers1

8

There are good answers regarding the GIL you can look at.

In short, if your tasks are CPU-bound (like the ones you posted), threads are not going to help you. Python threads are good for IO-bound tasks, like retrieving a web page.

R. Max
  • 6,624
  • 1
  • 27
  • 34
  • Thanks Rho! I'd upvote your comment but I lack the rep. Why is it that CPU-bound tasks can't run concurrently? Thinking of gaming, aren't most tasks CPU-bound? (like simulating something offscreen) – Jim V Oct 27 '13 at 03:26
  • 1
    You can have concurrency in python. For an extended explanation see here: http://jessenoller.com/blog/2009/02/01/python-threads-and-the-global-interpreter-lock For example, think having an (event) loop that performs a bit of a task in the first loop and a bit of another task in the next loop and so on. And take a look at this minecraft clone https://github.com/fogleman/Minecraft/blob/master/main.py#L409 – R. Max Oct 27 '13 at 03:40
  • Great info; I'll be studying it all in depth. Without the GIL, would my code run concurrently as is? Can other languages run CPU-bound threads in parallel? – Jim V Oct 27 '13 at 03:50
  • 1
    The GIL thing is more about the implementation. The default implementation of python is CPython, there have been attempts to have a GIL-free python implementation but were unsuccessful. I can't say if all but many language have threads with true parallelism (i.e. c, java, etc). As a side note, event-driven concurrency is very successful for networking software. – R. Max Oct 27 '13 at 03:57