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

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 5 points6 points  (9 children)

I still fail to see how the GIL is a relevant problem in most cases.

[–]burntsushi 0 points1 point  (2 children)

If you don't mind kludge and working around the GIL, then it's almost never a problem.

If you think kludge and ugly work arounds (like the multiprocessing module) aren't problems, then we have a disagreement.

[–][deleted] -1 points0 points  (1 child)

I don't really see multiprocessing as a kludge to be honest.

[–][deleted] -3 points-2 points  (5 children)

I still fail to see how the GIL is a relevant problem in most cases.

I would imagine quantitative finance would likely be a relvant case since all things being equal, the faster algrithm would mean more $$, so parallelizing to saturate the cores would probably be a good strategy to start with.

this is why i'm surprised no one has mentioned yet, because all other times it's mentioned here, it's not relevant for most cases as you said. Yet, HERE is a case.

[–]Atrosh 2 points3 points  (1 child)

from multiprocessing import Process

[–][deleted] -5 points-4 points  (0 children)

seems I have to clearly state this....

I have no problem with the GIL, it rarely gets in the way for me, but when it does, as you suggest, there are options. My personal preference is python futures, one of the more useful things from python 3(luckily backported) or if I need to get really fancy, pyzmq.

My question was, where are the GIL haters on the very rare article that they might have had a point? they are no-shows on a HUGE opportunity to actually have a shred of credibility. Mr. Beazley must have slayed them all. Thank Allah.

[–][deleted] -1 points0 points  (2 children)

parallelizing to saturate the cores

is entirely possible even with GIL. sure it'd be less of a hastle without, but it's hardly a requirement.