Bien que je ne connaisse pas grand chose en HPC (j'ai seulement fait un peu de CUDA, pas mal d'OpenMP, et un peu de vectorisation manuelle), je me permet de donner mon point de vue personnel.
C'est tout de même intéressant de tracer des parallèles entre les monde du HPC, GPGPU, multithreading et SIMD puisque les technologies semblent converger.
Des clusters HPC utilisent des cartes Tesla et les processeurs génériques embarquent des unités de calcul SIMD génériques contrôlées par du microcode. Dans le futur, on peut imaginer une fusion des concepts SIMD CPU et GPU. L'avantage par rapport au GPGPU est d'éviter le goulot d'étranglement entre les mémoires séparées. Le multithreading CPU, avec cœur de calcul et caches séparés, montre ses limites (bien que des progrès sont toujours d'actualité). Actuellement le hardware se démène pour "simuler" l'ancien modèle d'exécution en terme de cohérence du cache, etc.
Le chargement de noyau de calcul sur le CPU s'exécutant simultanément sur plusieurs unités permettrai d'éviter la duplication du pipeline d'instruction et les problèmes de localité et cohérence des données.
Les vieux (et vénérables) langages de programmations système comme le C s'adaptent mal à ces problèmes : il y a trop d'effets de bord et d'aliasings possible. Les concepts d'immutabilité, de portée des effets de bord et de compossibilité sont des atouts pour le programmeurs mais aussi pour la vectorisation/parallélisation par compilateur. Cela permet une analyse plus poussée des flux de donnés (dataflow analysis) et ainsi de découper automatiquement le calcul pour la parallélisation sur plusieurs niveaux. En production je ne vois que les cadriciels Map/Reduce qui vont dans ce sens, et à un niveau qui ne descend pas en dessous du nœud de calcul.
Bref, on peut espérer des progrès au niveau de la formalisation et résolution automatique de la distribution du calcul et de la localité des données sur plusieurs échelles :
Historiquement, cette problématique a toujours existé. Lors de la conception de ses superordinateur, Seymour Cray a dû adapter la conception mécanique pour la communication entre les unités tout combattant les soucis thermiques (d'où la géométrie en C). C'est le sort inévitable de l'entropie...
[^] # Re: Intéressant
Posté par Piezo . En réponse au journal Petit tour d’horizon de la haute performance et du parallélisme. Évalué à 2.
Bien que je ne connaisse pas grand chose en HPC (j'ai seulement fait un peu de CUDA, pas mal d'OpenMP, et un peu de vectorisation manuelle), je me permet de donner mon point de vue personnel.
C'est tout de même intéressant de tracer des parallèles entre les monde du HPC, GPGPU, multithreading et SIMD puisque les technologies semblent converger.
Des clusters HPC utilisent des cartes Tesla et les processeurs génériques embarquent des unités de calcul SIMD génériques contrôlées par du microcode. Dans le futur, on peut imaginer une fusion des concepts SIMD CPU et GPU. L'avantage par rapport au GPGPU est d'éviter le goulot d'étranglement entre les mémoires séparées. Le multithreading CPU, avec cœur de calcul et caches séparés, montre ses limites (bien que des progrès sont toujours d'actualité). Actuellement le hardware se démène pour "simuler" l'ancien modèle d'exécution en terme de cohérence du cache, etc.
Le chargement de noyau de calcul sur le CPU s'exécutant simultanément sur plusieurs unités permettrai d'éviter la duplication du pipeline d'instruction et les problèmes de localité et cohérence des données.
Les vieux (et vénérables) langages de programmations système comme le C s'adaptent mal à ces problèmes : il y a trop d'effets de bord et d'aliasings possible. Les concepts d'immutabilité, de portée des effets de bord et de compossibilité sont des atouts pour le programmeurs mais aussi pour la vectorisation/parallélisation par compilateur. Cela permet une analyse plus poussée des flux de donnés (dataflow analysis) et ainsi de découper automatiquement le calcul pour la parallélisation sur plusieurs niveaux. En production je ne vois que les cadriciels Map/Reduce qui vont dans ce sens, et à un niveau qui ne descend pas en dessous du nœud de calcul.
Bref, on peut espérer des progrès au niveau de la formalisation et résolution automatique de la distribution du calcul et de la localité des données sur plusieurs échelles :
Historiquement, cette problématique a toujours existé. Lors de la conception de ses superordinateur, Seymour Cray a dû adapter la conception mécanique pour la communication entre les unités tout combattant les soucis thermiques (d'où la géométrie en C). C'est le sort inévitable de l'entropie...
Sinon, petite typo :