Salut!
C'est vrai; alors, il faut faire des choix.Seulement comme ça évolue trop rapidement on peut pas tout maîtriser.
Jean-Marc Blanc
Salut!
C'est vrai; alors, il faut faire des choix.Seulement comme ça évolue trop rapidement on peut pas tout maîtriser.
Jean-Marc Blanc
Calcul numérique de processus industriels
Formation, conseil, développement
Point n'est besoin d'espérer pour entreprendre, ni de réussir pour persévérer. (Guillaume le Taiseux)
Cela ne sert à rien de paralléliser tes taches "enregistre", "cherche", "recalcule" et "compte" pour un même acheteur puisque chacune de ces tâches est dépendante de la précédente (où alors tu es capable de débiter le compte du mec sans qu'il ait choisi son article ... ce qui est du vol )
Sur un serveur d'application, chaque requête entrante est associée à un thread et chaque thread sera exécuté entièrement sur 1 proc. Dans l'exemple que tu donnes, le développeur n'a rien à gérer.
On parle des développeurs mais moi je pense que tant que les langages n'intègrent pas intrinsèquement la notion de parallélisme dans leur syntaxe, on restera avec une gestion historique et complexe de ce parallélisme.
Plus on abstrait cette notion, plus elle sera utilisée.
Bonjour
Je trouve assez extraordinaire d'arriver à justifier une phrase qui ne veut rien dire par un lien d'une extrême qualité ! (Grand merci pour ce lien).
1) parler de "loi de Moore", ça a à peu près autant de sens que de parler de "loi d'Elisabeth Teissier". Il ne s'agit de rien de plus que d'une conjecture, d'une prédiction, d'une prévision.
2) l'article explique que cette prédiction (pour peu qu'on trouve un consensus sur sa signification) a globalement toujours été fausse
3) comment peut-on dire qu'une prédiction, serait "à la base de la technologie des processeurs", alors que cette technologie existait avant le prédiction, et que la prédiction s'est révélée fausse ??
Consultant / formateur Oracle indépendant
Certifié OCP 12c, 11g, 10g ; sécurité 11g
Ma dernière formation Oracle 19c publiée sur Linkedin : https://fr.linkedin.com/learning/oracle-19c-l-administration
Je n'ai pas envie de lancer un débat trollesque mais je trouve que cet article n'est pas assez clair sur certains points.
Déjà la définition de la loi de Moore n'est pas exacte. L'auteur en donne une définition précise :
Elle stipule que c'est le nombre de transistors sur un circuit intégré qui doublera tous les 18 mois pas la performance du CPU. L'augmentation de la performance CPUs n'est qu'une conséquence directe de la loi Moore.The backdrop to this issue is a paper written by Gordon Moore, the co-founder of Intel ( INTC - news - people ). Published 45 years ago this month, the paper predicted the number of transistors on an integrated circuit would double each year (later revised to doubling every 18 months). This prediction laid the groundwork for another prediction: that doubling the number of transistors would also double the performance of CPUs every 18 months.
Aujourd'hui, on constate que bien que la vitesse des CPU a baissé mais le nombre de transitors que l'on met sur un circuit a augmenté.
Programmation dite "linéaire"??? Tu parles de la programmation batch?? Cela fait plusieurs années (> 20) que l'on fait du temps partagé. Cela plusieurs années que les processeurs peuvent lire des blocs d'instruction.
Il est bien possible de faire la programmation parallèle sur une architecture monocoeur. Sinon les librairies développées en C (pthread), en ou java (java.lang.Runnable) ou dans n'importe quel langage n'aurait pas lieu d'etre.
Je ne sais pas pour d'autres, mais moi à la fac, j'en fais. On développe meme sur la PS3 pour faire des calculs matriciels.
Ce que B.AF suggérait c'était :
Version linéaire :
- proc1 : enregistre, cherche, recalcule, compte
Version Parallèle :
- proc1 : enregistre
- proc2 : cherche, recalcule
Lorsque proc1 et proc2 ont terminé :
- proc3 : compte
Dans la version linéaire, tu as la réponse en 4 temps.
Dans la version parallèle, seulement en 3 temps.
Du moins c'est la théorie, qui serait à peu près vrai à faible charge (si la machine n'a qu'une seule transaction à traiter, ou si tu fais du calcul lourd pour un seul utilisateur).
Mais sur un serveur, lorsque la charge augmente et que le serveur doit traiter un grand nombre de transactions simultanées, tu as un problème de files d'attentes qui se rajoute :
Tu n'as pas suffisament de processeurs pour traiter immédiatement toutes les opérations de chaque transactions.
- Donc dans la version linéaire : Tu fais la queue une fois. Ton tour arrive sur le CPU, tu fais tes 4 opérations et tu as la réponse.
- Dans la version parallèle, tu prends une première file d'attente pour le proc1 et tu exécutes les deux opérations. En même temps, tu prends une deuxième file d'attente pour le proc2 et tu fais ton opération. Une fois que les deux ont terminé (donc tu gardes la plus grande des deux durées : Attente1 + operation 1 + operation 2, Attente 2 + Opération 3), tu prends une troisième file d'attente pour avoir le processeur et exécuter la dernière opération.
Donc tu passes de 1 attente + 4 opérations à 2 attentes + 3 opérations.
Sachant que lorsque la charge augmente, la durée des opérations ne changent pas, mais les temps d'attentes augmentent avec la longueur des files...
Et pour couronner le tout, une fois que tu as obtenu le CPU, tu peux avoir besoin d'autres ressources pour effectuer ton traitement (par exemple des accès disques ou réseau)... C'est alors que surviennent les risques de blocages et de famines...
C'est toute la difficultée de la programmation parallèle, on ne peut pas découper n'importe quoi n'importe comment pour obtenir de meilleures performances. Il faut trouver la bonne architecture de découpage, et le bon ordonnencement des traitements.
C'est plus compliqué que ça.J'aurais limite tendance a dire la version linéaire : le proc n'est jamais en attente de la fin d'une tache vu qu'elles sont faites dans l'ordre donc pas de temps proc perdu.
Car en fait, même dans la version linéaire, tu vas faire des I/O (accès disques, réseaux...). Donc le processeur va être bloqué en attente des résultats.
Avec un minimum de parallélisme, le processeur pourrait être utilisé pour faire autre chose. Par exemple, commencer les calculs d'une autre transaction...
Donc il n'y a pas de réponse évidente à la question. Il faut savoir ce qu'on fait et ce qui se passe dans les traitements pour établir l'architecture qui donnera les meilleurs résultats :
- En termes de temps de réponse.
- En termes d'utilisation des ressources (charger au maximum les CPU pour qu'ils ne soient pas à se tourner les pouces alors qu'il y a des traitements en attente).
Il n'a jamais été dit que la programmation parallèle était une nouveauté. Bien sûr elle existe depuis l'apparition des traitements interactifs dans l'informatique. A la base c'était pour rentabiliser au mieux les processeurs en servant un autre utilisateur pendant que le premier réfléchissait à ce qu'il voulait faire.
Mais même si elle existe depuis longtemps, elle reste encore assez peu utilisée. Mis à part le système d'exploitation et les drivers de périphériques, la plupart des appli sont purement monotâches.
En grande partie à cause de la difficulté pour paralléliser efficacement un problème séquentiel par nature !
Depuis des années on a amélioré les performances des ordinateurs en faisant des processeurs plus rapides, afin que les traitements séquentiels soient plus performants.
Le sujet de cette discussion, c'est qu'aujourd'hui, les concepteurs des processeurs n'arrivent plus à gagner en performances pures.
Donc pour continuer à avoir des machines plus puissantes, à faire des traitements plus rapidement, il faut faire en sorte de se tourner vers le parallélisme.
Or s'il est assez simple de multiplier les CPU sur un serveur et gérer des transactions indépendantes en parallèle, il est beaucoup plus difficile de découper efficacement une même transaction en éléments parallélisables.
Les IRQ servent à interrompre le traitement en cours sur le processeur pour lui dire qu'un périphérique nécessite son attention.
Dans un fonctionnement parfaitement linéaire et synchrone, si tu dois lire un fichier, il va falloire que tu positionnes la tête de lecture au dessus du cylindre que tu veux lire, donc que tu attendes que le mouvement mécanique soit terminé. Il faut aussi que tu attendes que le secteur à lire passe sous la tête...
Tout ces temps d'attente sont relativement long. Le CPU aurait le temps de faire beaucoup de calcul pendant ce temps.
Donc dans un fonctionnement purement linéaire, tu as de nombreux temps d'attentes qui sont perdus et qui pourraient servir à autre chose.
Au contraire, avec un fonctionnement multi-tâche, tu as un premier traitement qui veut réaliser un accès disque. Il lance son I/O sur le périphérique et la tâche est bloquée jusqu'à ce que le périphérique ait terminé.
Donc le processeur est libre et va commuter pour exécuter une autre tâche activable.
Lorsque le périphérique a terminée son I/O, il va déclencher une IRQ pour que le processeur sache que l'opération est terminée. Il pourra alors rendre la première tâche activable, et elle reprendra son exécution dès que le CPU sera disponible...
Mais on est déjà dans une architecture parallèle. Pour tirer parti de ce fonctionnement, il faut avoir quelque chose à faire pendant qu'on attend la fin de l'I/O.
C'est comme ça qu'on peut faire du multi-tâche avec un seul CPU...
Désolé, je ne comprends pas ce que tu veux dire.Ou beaucoup plus simples, et moins gourmands en ressource que d'utiliser des multicores, mais l'inconvénient reste quand même le prix
Ah oui ça remonte quand même à 2 ans
En fait, je voulais m'interroger sur l'avantage d'utiliser des technolgies multicores pour le développement en parallèle, si toutefois ça s'avérait utile.Désolé, je ne comprends pas ce que tu veux dire.
Mettons que demain je me prenne un Athlon X6 (eh ouais je suis un fou ), je veux dire on reproduirait 6 * le développement parallèle, ou bien c'est prédestiné à carrément autre chose les technologies multicores ?
In CODE we trust
Loppsi (Brice, Sarkozy);
fatal error : cannot call to unprivated function !
Bonjour,
Ayant suivi une formation enseignant le parallelisme, je suis surpris de voir a quel point ce domaine est méconnu en informatique. D'ailleurs, ce que j'ai lu du débat jusqu'ici ne faisant que confirmer ce que je pensais.
Il n'y a pas un, mais des parallelismes. Et c'est d'ailleurs ce qui fait sa force, meme si c'est aussi ce qui participe a sa meconnaissance.
Si je reprend l'exemple :
La version lineaire 1 est en fait du parallelisme (cas tres particulier, qui ne sera efficace que dans de rares cas), de meme que les deux versions paralleles.Version linéaire 1 :
proc1 : enregistre,cherche,recalcule,compte
proc2 : enregistre,cherche,recalcule,compte
proc3 : enregistre,cherche,recalcule,compte
proc4 : enregistre,cherche,recalcule,compte
Version parallèle 1 :
proc1 : enregistre,enregistre,enregistre,enregistre
proc2 : cherche,cherche,cherche,cherche
proc3 : recalcule,recalcule,recalcule,recalcule
proc4 : compte,compte,compte,compte
Version linéaire 2 :
- proc1 : enregistre, cherche, recalcule, compte
Version Parallèle 2 :
- proc1 : enregistre
- proc2 : cherche, recalcule
Lorsque proc1 et proc2 ont terminé :
- proc3 : compte
La version parallele 2 est effectivement celle qui, dans le cas present, nous donne un meilleur temps, en ayant effectue une tache en 3 unites de temps au lieu de 4.
Mais le calcul parallele adresse principalement des calculs longs, pour lesquels le gain va etre sur la duree globale, et non pas sur le fait d'avoir une tache en moins.
Si on considere 4 processeurs, et un modele parallele en pipeline, on peut avoir la chose suivante (je passe volontairement la phase d'initialisation, et considere les calculs N a N+ ):
Ce modele permet, si on enleve les phases d'initialisation et de finalisation, de diviser le temps total de calcul par le nombre de processeurs !! Le gain est colossal, a condition que le probleme soit modelisable sous forme de pipeline, ce qui n'est pas toujours le cas.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5 proc1 : enregistre N, enregistre N+1, enregistre N+2, proc2 : cherche N-1, cherche N, cherche N+1, proc3 : calcul N-2, calcul N-1, calcul N, proc4 : compte N-3, compte N-2, compte N-1,
Pour en revenir a la question premiere :
Cela fait des annees que je milite pour le calcul parallele au sein des entreprises, mais je constate que l'idee actuellement la plus repandue est que ca ne sert a rien, il suffit de 2 choses :
- multi-threader et laisser faire l'OS
- acheter une machine plus puissante
De ce que j'ai vu, les entreprises n'ont pas encore pris conscience que la loi de Moore (stricto-cinsu, c'est a dire en nombre de transistor ) est obsolete, et que donc leur sacro-sainte regle a la noix de changer de machine ne pourra continuer a fonctionner.
Peut-etre que certains s'apercevront que le parallelisme est la meilleure solution. Meme si, je l'avoue, cela demande de former pas mal de monde. Mais que l'on commence deja par s'y mettre avec ceux qui ont des competences dans le domaine
Tu peux faire ce que tu veux : exécuter le même code sur des données d'entrées différentes, ou exécuter du code différent en fonction du processeur.
Tu peux aussi utiliser 4 processeurs pour une tache, 1 pour une autre et le dernier libre pour l'OS ou écouter de la musique.
Toutes les solutions sont envisageables. Le but est de trouver le meilleur rapport entre le temps de développement, la complexité de mise en oeuvre de la situation, le temps de calcul final, le type de processeurs à disposition, le nombre de processeurs, ...
Le bon parallélisme tient compte de tous ces paramètres, et te sort un joli programme miracle qui optimise tout ça. Enfin en théorie bien sûr
Okay ... de ce que j'ai compris, le développement en plus du multicores optimise la répartition des tâches en fonction de toutes les données parmi lesquelles celles que tu as citées.
C'est parfaitement clair, pour l'instant j'ai pas trop le temps de voir des tutoriels là-dessus, mais si un jour j'en ai l'occasion je penserais à ce thread et je suis ouvert à des tutoriels en C/C++ là-dessus.
En tout cas, je vous remercie de ce briefing
"Peut-être que certains s'apercevront que le parallélisme est la meilleure solution. Même si, je l'avoue, cela demande de former pas mal de monde. Mais que l'on commence déjà par s'y mettre avec ceux qui ont des compétences dans le domaine "
J'approuve totalement
In CODE we trust
Loppsi (Brice, Sarkozy);
fatal error : cannot call to unprivated function !
Je précise un peu : le développement du parallélisme doit se faire en plus de l'utilisation des multi-coeurs.
Si on prend, un PC standard avec un CPU a 4 coeurs, on peut envisager par exemple les scénarios suivants :
Mode normal : firefox, winamp, un petit jeu à la con dans un coin, avec en arrière-plan Thunderbird et open-office. Chacun doit pouvoir disposer d'un peu de puissance de calcul, et pour cela il semble raisonnable de laisser l'OS gérer le truc.
Mode gros jeu : la, incontestablement, le parallélisme explicite (c'est-à-dire que le jeu est développe pour utiliser plusieurs processeurs) devient intéressant : on calcule plusieurs choses en même temps sur les différents coeurs, et aussi sur le GPU de la carte graphique, qui se charge de l'affichage.
Dans ce cas, l'OS ne doit pas avoir en charge la répartition des différents calculs sur les processeurs ni sur les coeurs.
Ce mode est aussi applicable pour les PC que pour les serveurs, et pour tous les types d'applications. Mais il faut de la volonté, du temps, et de l'argent pour que ça commence à se démocratiser.
Si on prend mon cas à moi qui veut profiter des nouveautés qui sortent parce que le métier me tiens à coeur, je vais dépenser un budget pour avoir une carte mère récente , une CG récente et un pross récente avec une alim de base adaptée à la conso ... je pense que c'est plus de la volonté qu'il faut, après les autres facteurs temps et argent relèvent plus de l'indécision .
Enfin c'est perso mon avis. Je veux réellement apprendre en restant en veille technologique permanente.
Sinon pour en revenir au multicores, les cartes mères permettent de les activer ou pas, donc effectivement ça change rien au développement en parallèle et linéaire, sur un Core, après quand on active tout les coeurs, faudrait surtout se mettre à la page, et développer des méthodes permettant d'optimiser le parallèle en fonction des coeurs présents dans le pross ... enfin, moi je me la sens tester sur du multicores un script par exemple permettant d'effectuer du parallèle.
Bref, merci du renseignement, je reviendrais bientôt vers vous pour de plus amples informations
In CODE we trust
Loppsi (Brice, Sarkozy);
fatal error : cannot call to unprivated function !
Oui, "programmation parallèle" c'est un terme générique qui désigne simplement le fait de faire plusieurs choses en même temps.
Après il peut se décliner d'un grand nombre de façons (multi-threading, calculs vectoriels, ...).
Détrompe-toi. C'est le fonctionnement classique d'un serveur. Et c'est généralement ce qui donne les meilleures performances : Tu attends une fois pour obtenir le processeur, tu fais tes 4 opérations, tu as terminé.Si je reprends l'exemple :
La version linéaire 1 est en fait du parallélisme (cas très particulier , qui ne sera efficace que dans de rares cas),
D'un point de vue, théorie des files d'attente, tu es dans la configuration où tu as une file d'attente unique, avec N guichets pour dépiler la file. C'est la configuration optimale qui permet de minimiser le temps d'attente des clients et d'utiliser au maximum chaque guichet.
Dans les autres architectures, tu attends un processeur libre pratiquement à chaque opération.
Dans le premier cas, tu fais la queue une fois. Tu arrives au guichet, tu réalises toutes tes opérations.
Dans les autres cas, tu fais la queue une fois. Tu arrives au guichet, tu réalises une seule opération. Et tu retournes faire la queue pour pouvoir faire la deuxième.
Dans les deux cas, les guichets travaillent de la même façon. Le nombre total d'opérations traitées est le même. Le temps de traitement est le même. Mais dans le deuxième cas, tu ajoutes de nombreux temps d'attente qui allongent les temps de réponse... le tout à charge constante.
En fait, c'est la même chose que dans "linéaire 1", mais en pire : Le calcul se fait aussi en 4 temps, mais avec des synchronisations obligatoires entre chaque étape :Si on considère 4 processeurs, et un modelé parallèle en pipeline, on peut avoir la chose suivante (je passe volontairement la phase d'initialisation, et considère les calculs N a N+ ):
Ce modelé permet, si on enlève les phases d'initialisation et de finalisation, de diviser le temps total de calcul par le nombre de processeurs !! Le gain est colossal, à condition que le problème soit modélisable sous forme de pipeline, ce qui n'est pas toujours le cas.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5 proc1 : enregistre N, enregistre N+1, enregistre N+2, proc2 : cherche N-1, cherche N, cherche N+1, proc3 : calcul N-2, calcul N-1, calcul N, proc4 : compte N-3, compte N-2, compte N-1,
Proc1 exécute "enregistre N". Il faut attendre que Proc2 ait terminé "cherche N-1" pour pouvoir enchaîner "Cherche N". Et si Proc2 termine "Chercher N-1" avant que proc1 n'ait terminé "Enregistre N", il va devoir attendre que Proc1 ait fini !
Dans cette version, tu vas diviser le temps de traitement global par le nombre de processeurs, mais il faut ajouter les temps d'attente dûs aux synchronisations.
Dans la version linéaire 1, tu n'as pas ces temps de synchronisation alors que tu divises également le temps de traitement global par le nombre de CPU du fait que tu traites une transaction par CPU.
Mais dans la pratique, du fait des blocages, linéaire 1 et parallèle 2 seront identiques, car tu découpes ton traitement en tâches à exécuter, et l'OS va attribuer le CPU en fonction des tâches activables. Dès que le traitement d'une étape va bloquer sur une E/S, le CPU sera ré-attribué à une autre tâche, ce qui donnera parallèle 2 en pratique.
Pourtant comme tu l'as dit toi-même, multi-threader c'est déjà du calcul parallèle.Pour en revenir a la question première :
Cela fait des années que je milite pour le calcul parallèle au sein des entreprises, mais je constate que l'idée actuellement la plus répandue est que ça ne sert a rien, il suffit de 2 choses :
- multi-threader et laisser faire l'OS
- acheter une machine plus puissante
Et oui, il vaut mieux faire confiance à l'OS pour attribuer le CPU aux threads activables plutôt que d'essayer de faire le travail à sa place.
Je reprends ton exemple de Parallèle 2. Si tu affectes les tâches aux CPU sans qu'un CPU ne puisse servir à un autre traitement, tu vas rapidement rencontrer des problèmes de synchronisation : Les 4 opérations ne mettant pas exactement le même temps pour s'exécuter, le CPU qui exécute la tâche la plus longue sera rapidement saturé, tandis que les autres seront en famine...
Si tu laisses faire l'OS, il fera en sorte que les CPU soient chargés au maximum de ce qui est exécutable.
Le jeu est un bon exemple où le parallélisme est intéressant en effet. Mais pas en attribuant explicitement les tâches aux CPU.Envoyé par gangsoleil
C'est même un bon exemple d'inefficacité : le GPU ne peut exécuter que des calculs graphiques. Donc si les CPU sont saturés par exemple pour calculer l'IA, tu ne peux pas utiliser la puissance du GPU pour décharger le CPU.
C'est un peu moins vrai dans l'autre sens, mais même dans ce cas, on ne fait pas un équilibrage dynamique de la charge entre "calcule par le GPU" ou calcul par le CPU.
Donc on se retrouve avec une puissance de calcul d'un côté qui n'est pas utilisée, et une autre de l'autre qui est saturée !
Bon dans ce cas, on ne peut pas vraiment faire autrement.
Mais le principe reste le même si tu réserves manuellement les CPU pour des tâches données.
Ca a un sens si tu fais du temps réel et que tu veux être sûr d'avoir un CPU disponible pour réagir à un événement donné critique, mais si tu cherches une utilisation optimale de ta puissance de calcul, il ne faut jamais qu'un CPU se tourne les pouces (ou alors il qu'a ce moment il n'y ait rien à faire).
Et le meilleur moyen d'y parvenir, c'est de laisser l'OS attribuer le CPU aux tâches activables.
Et bien si, si tu programmes en linéaire, tu ne multi-thread pas ton appli. Donc tu ne tireras profis des différents coeurs que si tu as d'autres applications à exécuter en même temps, ou que c'est un serveur qui exécute plusieurs transactions en même temps (mais dans ce cas, c'est le serveur qui est multi-threadé). Pour une appli cliente pure, ce n'est pas très intéressant. Tu as acheté de la puissance de calcul que tu n'utilises pas.Envoyé par sparthane777
Pour faire de la programmation parallèle dans ton appli, il faut la multi-threadée, mettre en place les synchros indispensables.
Et ça ne servira probablement à rien dans l'hypothèse d'un serveur.
Bonjour,
Dans mon post, j'ai confondu deux cas. Merci de m'avoir corrigé.
Concernant le calcul sur GPU, cela fait l'objet actuellement de tres nombreuses recherches, afin de pouvoir calculer dessus et aussi de pouvoir recuperer le resultat (ce qui est evident avec un CPU et qui ne l'est plus sur un GPU). Mais il s'agit la d'un autre debat.
Concernant le fait de laisser un OS organiser les processus sur les differents coeurs disponibles, je ne suis pas d'accord avec toi pour dire que c'est la meilleure chose a faire. Ou tout du moins pas tant que les algorithmes des OS seront ceux qui sont actuellement implementes.
Prenons un programme mono-threade, qui prend 100% d'un coeur. Faisons-le tourner sur une machine à 4 coeurs, avec un OS actuel, et regardons ce qui se passe :
Le système te dit que le CPU global est utilisé à 25%, ce qui est vrai
Si tu regardes la charge réelle par CPU, tu t'aperçois que ton processus se ballade un quantum sur un coeur, deux sur un autre, etc etc etc ... Ceci est également vrai sur des machines multi-processeurs.
Dans ce cas précis, tu as 3 CPU qui ne font rien, et un qui tourne à bloc. Et plutôt que de dédier un CPU à cette tache, ce qui implique de ne pas avoir a recharger tous les registres et les mémoires caches, le système le ballade de partout, perdant un temps fou.
D'ailleurs, si tu as l'occasion de faire le test en dediant un processeur du système à ta tache, tu verras le gain de performance (enfin la encore, ce n'est pas vrai, car ça va dépendre de la tache, et principalement de ses accès mémoires).
Je pense que le problème du parallélisme est bien montré ici : il est nécessaire de l'adapter en fonction d'un très grand nombre de paramètres, et il est difficile de trouver des règles géneriques.
On peut aussi évoquer le parallélisme utilisé par les physiciens, qui programment en Fortran. Pourquoi ce langage ?? L'une des raisons est qu'il existe des compilateurs qui sont capables de générer des codes parallèles à partir de code linéaire. Alors certes, on n'a pas le même gain que si le programme était écrit de manière parallèle, mais cela ne mobilise pas un informaticien en plus du physicien lors de la phase de developpement. Et le gain par rapport à un programme linéaire est tout même important d'après ce que j'ai compris.
Et moi qui croyais que le seul instrument fiable de traitement parallèle de l'information était le Yi-King...
La sécurité de l'emploi
"Ce n’est pas une pratique médicale sensée que de risquer sa vie en se soumettant à une intervention probablement inefficace afin d’éviter une maladie qui ne surviendra vraisemblablement jamais."
Docteur Kris Gaublomme, médecin belge ("Vaccins et maladies auto-immunes")
La situation que tu décris n'est un problème que dans le cas où :
1. La tâche dure suffisamment longtemps sans réaliser la moindre I/O ni synchronisation pour se faire préempter.
2. Le traitement qui est aussi long est capable de travailler en ayant toutes les données dans le cache, sans jamais aller chercher de données en mémoire centrale.
C'est quand même un cas assez rare. D'autre part, tu ne peux changer de coeur qu'à l'issue de la fenêtre de préemption (ou d'une synchronisation), et même à ce moment-là, il n'est pas dit que l'OS te réaffecte sur un autre.
Mais la plupart du temps, tu n'utilises pas le CPU pendant plus de 15 minutes sans réaliser une E/S (ou alors il faut revoir ton algorithme...). Donc ta tâche va être suspendue en attente d'une E/S.
Et au moment où elle pourra repartir, tu as tout intérêt à ce qu'elle reparte sur le premier CPU disponible, plutôt que de devoir attendre que celui sur lequel tu l'as affecté soit libre !
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager