• # Python sur du multicoeur ?

    Posté par  . Évalué à 2.

    Si je me mets à coder des projets persos, je choisirais bien Python comme langage. Cependant il y a quelque chose qui me bloque : j'ai l'impression qu'il est impossible de tirer parti des processeurs multicoeurs à cause d'un « big kernel lock » dans l'interpréteur (écrit en C). Est-ce que les spécialistes Pyhton qui ne manqueront pas de passer par ici auraient plus d'informations ? Est-ce que cela veut dire qu'il faut écrire tout le code multithreadé en C et l'appeler depuis Python ?

    • [^] # Re: Python sur du multicoeur ?

      Posté par  . Évalué à 3.

      En effet, python 2.X est pour l'instant bloqué sur un Core. Cependant, il existe plusieurs modules permettant de contourner ce problème.

      http://www.parallelpython.com/

      http://www.corepy.org/

      et en prime, un thread bien trollesque sur la question http://www.thescripts.com/forum/threadnav20629-1-10.html

    • [^] # Re: Python sur du multicoeur ?

      Posté par  . Évalué à 3.

      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.

      = 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.

      • [^] # Re: Python sur du multicoeur ?

        Posté par  . Évalué à 2.

        IPython (un shell Python aux hormones) est en train de développer une version spéciale pour le calcul parallèle :
        http://ipython.scipy.org/moin/Parallel_Computing

        Les vidéos présentées à la PyCon2007 sont particulièrement intéressantes (elles sont dans les tgz) :
        http://ipython.scipy.org/talks/0702_pycon/

      • [^] # Re: Python sur du multicoeur ?

        Posté par  . Évalué à 2.

        Ou comment condamner son langage a servir des pages web.

        Ce qui m'étonne c'est qu'ils ont tenté de faire une implémentation intégralement thread safe, alors qu'en général, on fait la politique de l'autruche en ajoutant des mécanismes nécessaire pour que le développeur puisse faire du thread safe. Par exemple il parle du comptage de référence pour le garbage collector. C'est fallacieux ! toutes les technos que je connais un peu utilisent un garbage collector (ou toute autre structure partagée) par thread, et c'est au développeur de déclarer les variables partagés, dont les références seront comptées autrement, et ailleurs. Et cela se résout très bien, parce qu'en général on se sert de très peut de variables partagées, et on les manipule prudemment.

        Par contre une chose est claire, il est impossible (a ce que je sais) de faire du multi thread de manière transparente sur des langages non fonctionnels. Mais je ne pense pas que ce soit une bonne raison pour totalement brider une technologie a du mono thread. Faire une belle technologie c'est bien, mais quand les solution propres n'existe pas (j'ai bien dit n'existe pas), il reste toujours moyen de faire quelque chose de moins parfait, et laisser la responsabilité au développeur de l'utiliser.

  • # Je me demande si ...

    Posté par  . Évalué à 3.

    Il est prévu de le traduire en français ?

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.