Je ne suis pas complètement à l'aise avec le fonctionnement interne de CPython, mais de ce que j'ai compris au sujet de la gestion des multicores c'est que, dans toutes les solutions testées jusqu'à présent, l'overhead imposé par les mecanismes de préservation et de changement de contexte, ainsi que tout ce qui a trait à la synchronisation et au partage de l'espace mémoire, rendait marginale le gain de performance apporté par un second coeur.
La bonne pratique, pour le moment, serait donc de lancer plusieurs instances de l'interpréteur, le noyau se chargeant de les répartir entre les coeurs, et d'utiliser, si besoin, un mécanisme d'IPC pour communiquer entre les processus. En particulier, Twisted (http://twistedmatrix.com/trac/) est un framework évènementiel fabuleux pour ce genre d'architecture.
Q. Multi-core processors will be standard even on laptops in the near future. Is Python 3.0 going to get rid of the GIL (Global Interpreter Lock) in order to be able to benefit from this feature?
A. No. We're not changing the CPython implementation much. Getting rid of the GIL would be a massive rewrite of the interpreter because all the internal data structures (and the reference counting operations) would have to be made thread-safe. This was tried once before (in the late '90s by Greg Stein) and the resulting interpreter ran twice as slow. If you have multiple CPUs and you want to use them all, fork off as many processes as you have CPUs. (You write your web application to be easily scalable, don't you? So if you can run several copies on different boxes it should be trivial to run several copies on the same box as well.) If you really want "true" multi-threading for Python, use Jython or IronPython; the JVM and the CLR do support multi-CPU threads. Of course, be prepared for deadlocks, live-locks, race conditions, and all the other nuisances that come with multi-threaded code.
[^] # Re: Python sur du multicoeur ?
Posté par Yoann A. . En réponse au journal sortie du premier numéro de Python Magazine. Évalué à 3.
La bonne pratique, pour le moment, serait donc de lancer plusieurs instances de l'interpréteur, le noyau se chargeant de les répartir entre les coeurs, et d'utiliser, si besoin, un mécanisme d'IPC pour communiquer entre les processus. En particulier, Twisted (http://twistedmatrix.com/trac/) est un framework évènementiel fabuleux pour ce genre d'architecture.
= Python 3000 FAQ =
http://www.artima.com/weblogs/viewpost.jsp?thread=211200
Q. Multi-core processors will be standard even on laptops in the near future. Is Python 3.0 going to get rid of the GIL (Global Interpreter Lock) in order to be able to benefit from this feature?
A. No. We're not changing the CPython implementation much. Getting rid of the GIL would be a massive rewrite of the interpreter because all the internal data structures (and the reference counting operations) would have to be made thread-safe. This was tried once before (in the late '90s by Greg Stein) and the resulting interpreter ran twice as slow. If you have multiple CPUs and you want to use them all, fork off as many processes as you have CPUs. (You write your web application to be easily scalable, don't you? So if you can run several copies on different boxes it should be trivial to run several copies on the same box as well.) If you really want "true" multi-threading for Python, use Jython or IronPython; the JVM and the CLR do support multi-CPU threads. Of course, be prepared for deadlocks, live-locks, race conditions, and all the other nuisances that come with multi-threaded code.