Non, mais là, c’est pour parallèliser l’execution de make. C’est une fonctionnalité de make, mais ça ne fait pas de tes executables en c (entre parenthèses, make ne se limite pas à la compil de code c) des programmes qui exploitent le parallèlisme.
De plus, même avec CONCURRENCY_LEVEL = 3, ça ne garantit pas que l’ordonnanceur, si ton proco est déjà occupé par autrechose, va répartir la charge, juste qu’il le fera s’il le juge utile.
Et tu ne peux pas choisir toi même la manière dont make répartit sa charge.
Bref, ça n’a rien à voir avec l’optimisation en parallèlisme d’un script python.
bon et comment sa ce fait que c’est plus rapide avec make avec cette option que sans c’est a mon avis la qu’il y a quelque chose qui m’echappe ?
L’ordonnanceur Linux est excellent 
L’ordonnanceur Linux est excellent 
[/quote]
excellent certes, mai sa n’explique pas pourquoi c’est plus rapide avec !
Parceque sans cette option, make travaille en séquence, tâche aprés tâche.
L’option lui dit juste de lancer s’il peut jusqu’à CONCURENCY_LEVEL tâches en même temps, et s’il y a plusieurs processeurs l’ordonanceur les répartit.
Sans l’option, make lance une tâche, attend qu’elle soit finie, en lance une autre, etc…
En phase de développement, c’est plus facile de voir ou arrivent les erreurs quand ça compile en séquence. Quand c’est juste une recompil, autant parallèliser.
python ne tournera jamais en vrai “multithread”, en tout cas CPython. Ceci est du a l’architecture de python, qui utilise ce que l’on appelle le Global Interpreter Lock (GIL). Ce verrou global est utilisé notament pour la gestion du garbage collector a base de contage de références.
La seule façon de faire du vrai multithreading en python, c’est d’écrire les morceaux “critique” en C, et de les lancer en parallèle, tout en pensant a relacer le GIL dans la partie codée en C.
Sinon, il faut faire du multiprocessus 
Ok merci pour les info. bref le C y as pas mieux visiblement 
@ed > Si je ne m’abuse GIL est entrain d’être recodé dans le noyau pour ne plus être autant utilisé.
GIL 
cf ed.
dac merci 
J’ai confondu GIL (que je ne connais pas) avec le BKL
MisterFreez: le GIL c’est un truc propre a CPython, pour protéger ses structure de données contre les race conditions
MisterFreez: le GIL c’est un truc propre a CPython, pour protéger ses structure de données contre les race conditions [/quote]
Carrément à cette implémentation.
puisque la productivité (environ 10 fois supérieure avec python) ne te pose pas de problème, ni la portabilité (python est éxécuté par un processeur virtuel donc portable), alors C n’est pas ce qu’il te faut: code en assembleur ! 
compare ce qui est comparable, un interprété sera toujours plus lent qu’un compilé, c’est logique. maintenant, python t’offre d’autres choses que C ne propose pas en natif:
-une gestion de la mémoire automatique via le garbage collector
-des types primitifs extrêmement pratiques (listes non typées, dictionnaires, etc)
-(celui là je suis pas sûr je ne connais pas assez le C), le multi-héritage
-une masse énormes de librairies pour faire à peu près tout et n’imp
et si vraiment les parties critiques de ton appli doivent être optimisées, il est possible d’interfacer python avec du C…
[ceci n’était pas un message du comité python même si ca a du y ressembler 
]
puisque la productivité (environ 10 fois supérieure avec python) ne te pose pas de problème, ni la portabilité (python est éxécuté par un processeur virtuel donc portable), alors C n’est pas ce qu’il te faut: code en assembleur ! [/quote]
python portable??? vu que la version 2.1 est incompatible avec la 2.3, redevient compatible avec la 2.4 (qui n’est donc plus compatible avec la 2.3), avant même de changer de machine, on n’est pas sur que le python du jour fonctionnera sur la même machine le lendemain! À cause de ça, j’ai refait autrement une application complète de plusieurs millers de lignes. Ne me parle pas de la portabilité de python…
[quote]
compare ce qui est comparable, un interprété sera toujours plus lent qu’un compilé, c’est logique. maintenant, python t’offre d’autres choses que C ne propose pas en natif:
-une gestion de la mémoire automatique via le garbage collector
-des types primitifs extrêmement pratiques (listes non typées, dictionnaires, etc)
-(celui là je suis pas sûr je ne connais pas assez le C), le multi-héritage
-une masse énormes de librairies pour faire à peu près tout et n’imp
et si vraiment les parties critiques de ton appli doivent être optimisées, il est possible d’interfacer python avec du C…
[ceci n’était pas un message du comité python même si ca a du y ressembler ][/quote]
python est en bonne place pour être le prochain support de programmation pour l’informatique en prépa…
et c’est un gage de qualité ? je sais pas trop comment le prendre en fait.
après c’est vrai que je code pas en python depuis assez longtemps pour avoir vécu les changement de version, et j’étais pas au courant de ce genre de problème même entre sous-versions. c’est pas top en effet.
Prépa scientifique ? Il y a pas mieux ? Genre haskel ou lisp ?
Moi j’aime bien le python qui est bien plus lisible que le perl. Le perl a d’autre avantage comme l’utilisation intesive des tables de hachages et des expressions régulières. Mais a utiliser un lanage de “interprété” (ils sont compilés “just in time”) il y a ruby qui a l’aire de roxxer complètement objet.
@meushi > Tu pense que le C possède peu de bibliothèque ??? 
Prépa scientifique ? Il y a pas mieux ? Genre haskel ou lisp ?
[/quote]
Le support pour l’option informatique reste Caml. Par contre, pour l’informatique «pour tous» (i.e le tronc commun à tous avec juste des rudiments d’algorithmie), le support actuel est Maple. SAGE avec python (qui a des qualités pédagogiques ne serait ce que par une indentation ayant une sémantique) est intéressant. Mais rien n’est décidé loin de là.
[quote]
Moi j’aime bien le python qui est bien plus lisible que le perl…[/quote]
Ça n’est pas faux (et en fait pas bien dur à réaliser).