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.
# Normalement, tu n'as pas à t'en préoccupper ...
Posté par Pol' uX (site web personnel) . En réponse au message Programmation multiprocesseur. É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 ?