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.
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.
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".
Tout à fait, mais c'est un long sujet ...
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.
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.")
[^] # Re: Normalement, tu n'as pas à t'en préoccupper ...
Posté par Pol' uX (site web personnel) . En réponse au message Programmation multiprocesseur. É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 ?