A l'heure où le multi coeur s'impose, juste pour les midinettes pas parce qu'on atteint des limites techniques en terme de miniaturisation, Python, degrade encore plus les performances que sur un mono-coeur.
C'est bien ce que j'appelle du discours de midinette, basé sur des lieux communs ingurgités ça et là sur le Web et régurgités sans réfléchir.
Ce n'est pas parce que nos ordinateurs sont parallèles que c'est forcément pour faire tourner une seule application à la fois (ou même une seule instance de cette application).
Même, ce n'est pas parce qu'une application est parallèle que cela doit être par le multi-threading.
(en passant, ton analyse des raisons du multi-coeur est un contresens amusant : si le multi-coeur « s'impose », c'est précisément grâce à la miniaturisation et non pas à cause de ses limites... Ben oui, il y a plus de place sur une puce bon marché que ne peut en faire raisonnablement usage un seul coeur, donc on rajoute des coeurs à côté. Note que cela n'empêche pas les coeurs individuels de devenir eux-mêmes plus puissants au fil du temps - compare un coeur d'Intel Nehalem et un coeur de Pentium 4 si tu n'es pas convaincu)
Et il vrai que le multiprocess est la panacée lorsque tu dois refactorer ton code.
Mais il n'y a pas de panacée, mon cher, en matière de parallélisme. Quelque soit la technique utilisée, c'est toujours beaucoup plus délicat de faire du code parallèle que du code strictement séquentiel, car il faut maîtriser tous les problèmes de synchronisation qui surgissent.
Ironiquement, quand on veut faire de la programmation multi-thread robuste, on en arrive souvent à utiliser les mêmes techniques que pour du multi-processing : par exemple du passage de messages.
C'est pas les pythonista qui affirment que python n'est pas qu'un langage de script et qu'on peut tout faire avec.
[^] # Re: Ça passe très bien :)
Posté par Antoine . En réponse à la dépêche Jython supporte maintenant Python 2.5. Évalué à 2.
C'est bien ce que j'appelle du discours de midinette, basé sur des lieux communs ingurgités ça et là sur le Web et régurgités sans réfléchir.
Ce n'est pas parce que nos ordinateurs sont parallèles que c'est forcément pour faire tourner une seule application à la fois (ou même une seule instance de cette application).
Même, ce n'est pas parce qu'une application est parallèle que cela doit être par le multi-threading.
(en passant, ton analyse des raisons du multi-coeur est un contresens amusant : si le multi-coeur « s'impose », c'est précisément grâce à la miniaturisation et non pas à cause de ses limites... Ben oui, il y a plus de place sur une puce bon marché que ne peut en faire raisonnablement usage un seul coeur, donc on rajoute des coeurs à côté. Note que cela n'empêche pas les coeurs individuels de devenir eux-mêmes plus puissants au fil du temps - compare un coeur d'Intel Nehalem et un coeur de Pentium 4 si tu n'es pas convaincu)
Et il vrai que le multiprocess est la panacée lorsque tu dois refactorer ton code.
Mais il n'y a pas de panacée, mon cher, en matière de parallélisme. Quelque soit la technique utilisée, c'est toujours beaucoup plus délicat de faire du code parallèle que du code strictement séquentiel, car il faut maîtriser tous les problèmes de synchronisation qui surgissent.
Ironiquement, quand on veut faire de la programmation multi-thread robuste, on en arrive souvent à utiliser les mêmes techniques que pour du multi-processing : par exemple du passage de messages.
C'est pas les pythonista qui affirment que python n'est pas qu'un langage de script et qu'on peut tout faire avec.
http://fr.wikipedia.org/wiki/Homme_de_paille_(rh%C3%A9toriqu(...)