This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author davin
Recipients Martin Ritter, davin, devin, docs@python, r.david.murray, rhettinger, sbt
Date 2016-07-04.19:29:36
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1467660576.43.0.391581659485.issue27422@psf.upfronthosting.co.za>
In-reply-to
Content
@r.david.murray:  Oh man, I was not going to go as far as advocate dropping the GIL.  :)

At least not in situations like this where the exploitable parallelism is meant to be at the Python level and not inside the Fortran code (or that was my understanding of the setup).  Martin had already mentioned the motivation to fork to avoid side effects possibly arising somewhere in that code.

In practice, after dropping the GIL the threads will likely use multiple of the cores -- though that's up to the OS kernel scheduler, that's what I've observed happening after temporarily dropping the GIL on both Windows and Linux systems.  

As to the benefit of CPU affinity, it depends -- it depends upon what my code was and what the OS and other system processes were busily doing at the time my code ran -- but I've never seen it hurt performance (even if the help was diminishingly small at times).  For certain situations, it has been worth doing.


Correction:  I have seen cpu affinity hurt performance when I make a bone-headed mistake and constrain too many things onto too few cores.  But that's a PEBCAK root cause.
History
Date User Action Args
2016-07-04 19:29:36davinsetrecipients: + davin, rhettinger, r.david.murray, docs@python, devin, sbt, Martin Ritter
2016-07-04 19:29:36davinsetmessageid: <1467660576.43.0.391581659485.issue27422@psf.upfronthosting.co.za>
2016-07-04 19:29:36davinlinkissue27422 messages
2016-07-04 19:29:36davincreate