Bonjour,
J'ai une petite question de débutant a laquelle je n'arrive pas a trouver la réponse : en C comment on optimise son code pour des multiprocesseurs ?
En fait je précise : j'ai un ordi qui a deux processeurs double-coeur (donc ca fait au total...). On fork ? on utilise les threads ?
Merci !
Forum Programmation.c Programmation multiprocesseur
16
jan.
2007
# tu l'as dis
Posté par TImaniac (site web personnel) . Évalué à 4.
A partir du moment où tu parrallélises un maximum ton code, tu permet à l'OS de répartir "intelligement" les tâches entre les coeurs/processeurs, et donc tu autorises une utilisation plus optimale des ressources de calcul.
# Normalement, tu n'as pas à t'en préoccupper ...
Posté par Pol' uX (site web personnel) . Évalué à 3.
L'OS sert justement de couche d'abstraction du matériel, c'est lui qui partage les ressources de la machine entre les différents processus s'exécutant. Dans ce cas, si tu fait un programme, et que l'exécution se déroule bien, tu n'as pas à te préoccuper de savoir si il fonctionne sur 1, 2 ou 64 processeurs.
En revanche, il est bon d'avoir une idée de ce qui se passe en réalité : si tu code un code séquentiel simple (genre du C de base), ton code ne sera pas parallélisable, et il n'aura aucun intérêt à occuper plus d'un processeur.
Si ensuite tu code un truc un peu plus sioux, genre avec des threads (ou en utilisant un langage qui "parallélise" le code de façon transparente), alors l'OS pourra éventuellement exécuter différentes parties sur différents processeurs, mais ce n'est pas obligé.
Dans la plupart des cas, la parallélisation du code doit avant tout être un besoin fonctionnel, et pas un soucis d'optimisation. Le fork() est une opération très lourde, et l'utilisation des threads n'est pas sans conséquence ... donc ce ne sont pas des opérations magiques. Malgré tout, la mode actuelle est de fournir des processeurs multicoeurs, mais il ne faut pas croire que ça fonctionne n fois mieux que des processeurs simples. (voir cet article, simple mais intéressant http://www.onversity.net/cgi-bin/progarti/art_aff.cgi?Eudo=b(...) ainsi que d'autres, sur le même site)
Mon expérience personnelle (dans d'autres domaines que l'informatique) me montre que l'optimisation n'est jamais au gout du jour. Si tu fait des conceptions soignées et réfléchies avant de pisser du code, il ne restera pas beaucoup de place pour l'apparition de choses facilement optimisable.
Adhérer à l'April, ça vous tente ?
[^] # Re: Normalement, tu n'as pas à t'en préoccupper ...
Posté par malin . Évalué à 3.
Pas sur d'avoir compris ta réponse, mais si tu suggères qu'un programme écrit naïvement peut être spontanément rendu parallèle par l'OS, c'est faux. Un programme écrit dans un langage compilé termine forcément en une suite séquentielle d'instructions assembleur exécutées sur un seul processeur. Les compilateurs et les OS n'en sont pas encore au point de transformer automagiquement un programme séquentiel en un programme parallèle.
Exceptions à cette règle: les langages spécialisés pour l'écriture de code parallèle. Ce sont généralement des extensions du C ou du Fortran dédiées à des processeurs spécialisés comme des DSP ou des cartes de traitement. On trouve dans ces langages des instructions pour demander explicitement la parallèlisation d'un jeu d'instructions, c'est loin d'être invisible, c'est très chiant à écrire et ardu à débugger. On ne peut pas franchement parler d'un langage qui "parallèlise".
La seule voie possible pour utiliser plusieurs processeurs est d'écrire du code qui se déroule dans des piles d'exécution différentes, donc sous Unix: soit des threads soit des processes. Dans les deux cas tu dois donc t'en préoccuper explicitement.
Les experts te diront que toute la difficulté de la programmation multi-tâches est liée à la façon de communiquer entre tâches et la gestion d'accès aux ressources communes. Il ne suffit pas d'appeler fork() ou pthread_create() pour simplement transformer un programme séquentiel en parallèle.
[^] # Re: Normalement, tu n'as pas à t'en préoccupper ...
Posté par Pol' uX (site web personnel) . Évalué à 1.
Bah c'est pas ce que j'ai dit, je voulais simplement dire que ce n'était pas la préoccupation d'un programmeur débutant. Si l'exécution de son programme de base correspond à ses besoins, il n'a pas à aller chercher la bêbête, sauf cas particulier.
Tout à fait, mais c'est un long sujet ...
Amhaamqj, sauf cas particulier, l'utilisation du multi-tâche doit venir d'un besoin fonctionnel (processus coopératifs, exécution concurrente ...), et pas d'une volonté d'optimisation, c'est un peu le message que j'essayais de faire passer. (cf Alan Cox : "A computer is a state machine. Threads are for people who can't program state machines.")
Adhérer à l'April, ça vous tente ?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.