[st3fan]

"""Does it work? Yes it's better: Sequential 23.5 seconds. Threaded 24.0 seconds."""

How is that better? It is an improvement over earlier versions of Python. Better would be if the threaded version would actually be twice as fast.

[mitchellh]

If you look at the code he used to test this, its completely CPU-bound, meaning that it requires the GIL to run. And since the GIL is, well, a "GIL," that means that only one can run at any single time.

Therefore, the expected behavior of running these two threads would be to have identical runtimes. That would be the "perfect" case with a GIL. So with this "better" GIL its actually near-perfect in this _simple_ case. (Like the presenter said, there needs to be more tests to study the behavior under heavier tasks)

What you're describing, with the threaded being "twice as fast" assumes that the threads will allow two python-instruction-bound tasks to run concurrently, which would require having no GIL.

[jnoller]

An improvement over the old implementation is better. "Fixed and Perfect" would be free-threading, where it would be twice as fast with threads.

I'll take incremental, concrete improvements anytime.

[Luyt]

If you really want to speed up your program, you have to parallelize and distribute the workload over multiple cores. Python has a module in the standard library for this, it's called 'multiprocessing'. See http://docs.python.org/library/multiprocessing.html

[rbanffy]

It won't help if you have to do stuff over a single shared data structure.

[st3fan]

Well you can of course. It is just a pain to do it.

[rbanffy]

That's a good point. I rarely had to do it and, when I could, I opted to distribute the data.

Still, Python needs better threading.

[whatusername]

From Slide 7: Sequential (Single Core) : 24.6s

Threaded (Dual Core) : 45.5s

Threaded (With a CPU core diabled) : 38.0s

23.5 / 24.0 is an improvement to both tests - and a significant improvement to the Threaded one.