Ytukyg

import time

import threading

import multiprocessing



def fn():

    '''since all 3 functions were identical you can just use one ...'''

    x = 0

    while  x < 100000000:

        x += 1









def TEST_THREADS():

    new_thread1  = threading.Thread(target = fn , args = ())

    new_thread2  = threading.Thread(target = fn, args = ())

    new_thread1.start()

    new_thread2.start()

    new_thread1.join()

    new_thread2.join()



def TEST_NORMAL():

    fn()

    fn()



def TEST_MULTIPROCESSING():

    new_thread1  = multiprocessing.Process(target = fn , args = ())

    new_thread2  = multiprocessing.Process(target = fn, args = ())

    new_thread1.start()

    new_thread2.start()

    new_thread1.join()

    new_thread2.join()

if __name__ == "__main__":  

    '''It is very important to use name == __main__ guard code with threads         and multiprocessing'''

    import timeit

    print ("Time to Run 1x: %0.2fs"%(timeit.timeit(fn,number=1),))

    print ("NORMAL:%0.2fs"%(timeit.timeit(TEST_NORMAL,number=1),))

    print ("Threaded: %0.2fs"%(timeit.timeit(TEST_THREADS,number=1),))

    print ("Multiprocessing: %0.2fs"%    (timeit.timeit(TEST_MULTIPROCESSING,number=1),))

I found interesting presentetion about GIL and Threading:
http://www.dabeaz.com/python/NewGIL.pdf
So I wrote similar code, but get strange results:

Time to Run 1x: 11.60s

NORMAL:23.15s

Threaded: 23.43s

Multiprocessing: 1.19s

As you can see, threading method ran faster than normal one or equally (0.28s not too much).
I found some articles and similar questions, but everywhere results were like in presentetion- threading is slower.

Am I doing something wrong or new Python version improved GIL?

However, Multiprocessing also went crazy and work 20x faster than others! Is it ok?

In modern Python, the GIL isn't as bad as it used to be (previously, you could expect CPU bound threaded code to run meaningfully slower), so your observation is roughly what you'd expect.

From personal experience, a bunch of CPU bound threads on CPython 2.7 could use close to two cores of CPU, and accomplish less than 75% of a core's worth of work. Since they rewrote the GIL in CPython 3.2, that overhead largely disappeared; you still don't gain anything from the threading, but you end up using 1-1.1 cores' worth of compute and accomplish 95-100% of a core's worth of work. Basically, the GIL doesn't meaningfully slow code anymore, but it still prevents you from reaping a benefit from threading with CPU bound code that isn't based on third party GIL-releasing extensions like numpy.