> la difficulté de créer des programmes efficaces avec des processus se déroulant en parallèle.
Sans meme aller jusqu'a l'efficacite, concevoir et debugger un programme dont les morceaux s'executent en parallele est enormement plus complexe que de concevoir et debugger un programme normal.
Perso, je pense que les threads ne doivent etre utilises qu'en cas d'extreme necessite couplee avec une necessite extreme. Genre calculs mathematiques, programmes gerant n connexions, etc.
Pour parallelise un programme plutot monotache dans son fonctionnement, c'est tout de suite beaucoup plus complique. Il faut isoler des portions du programme qui n'ont pas besoin d'ecrire des donnes communes, il faut regarder l'ordonancement de chaque tache pour voir si on peut pas en lancer qqs'une avant les autres, etc.
Je prefere plutot que mon noyau et son scheduler qui s'occupe de paralleliser l'utilisation des ressources de ma machine, que le compilateur qui essaye de paralleliser un programme.
Pour en revenir aux programmes pseudo-monotaches, je me demande a quel point ce n'est pas plus simple de faire un scheduler interne (ce qu'a fait mplayer) que de faire de la programmation par thread a tout va. Au moins, avec ton scheduler, tu sais ou tu vas.
[^] # Re: Toujours pas l'intégration de GOMP...
Posté par Philippe F (site web personnel) . En réponse à la dépêche Sortie de la version 4.1 du compilateur GCC. Évalué à 4.
Sans meme aller jusqu'a l'efficacite, concevoir et debugger un programme dont les morceaux s'executent en parallele est enormement plus complexe que de concevoir et debugger un programme normal.
Perso, je pense que les threads ne doivent etre utilises qu'en cas d'extreme necessite couplee avec une necessite extreme. Genre calculs mathematiques, programmes gerant n connexions, etc.
Pour parallelise un programme plutot monotache dans son fonctionnement, c'est tout de suite beaucoup plus complique. Il faut isoler des portions du programme qui n'ont pas besoin d'ecrire des donnes communes, il faut regarder l'ordonancement de chaque tache pour voir si on peut pas en lancer qqs'une avant les autres, etc.
Je prefere plutot que mon noyau et son scheduler qui s'occupe de paralleliser l'utilisation des ressources de ma machine, que le compilateur qui essaye de paralleliser un programme.
Pour en revenir aux programmes pseudo-monotaches, je me demande a quel point ce n'est pas plus simple de faire un scheduler interne (ce qu'a fait mplayer) que de faire de la programmation par thread a tout va. Au moins, avec ton scheduler, tu sais ou tu vas.