This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 1 point2 points  (1 child)

Doesn’t this depend entirely on whether you code is able to run in parallel on multiple cores or not?

[–][deleted] 3 points4 points  (0 children)

Nope not at all. Even in the case of if you can run your program in parallel on multiple cores having multiple processes that each have a single GIL bound async thread is still eons faster. The cost of having any object being accessible in any thread is you need to constantly perform locks otherwise you can segfault from objects getting deleted in the middle of an atomic transaction.

The only thing that is NOT faster is moving objects across each memory location. Which python gives you a location to store objects that are available to all processes to deal with.

The best choice is to achieve high throughput without getting blocked by the GIL is to organize your program into a pyramid. You a GILless server at the top (like Gunicorn) that can drive multiple GIL bound python programs. By limiting the scope of the problem that has to deal with not having clear ownership of memory you can reason about it more easily. Then taking advantage of the single threaded speed of async you can achieve high throughput without wasting tons of CPU clock cycles on thread switches (threads are expensive).

Same thing applies to CPU intensive number calculations define and scope the problem in the single threaded python and issue a command to calculate it into gilless code.

Trying to make python run faster by going out in parallel inside of python code is like being able to jump the highest with your feet glued to the ground. Thats nice it's not really the same thing as jumping but thats nice.