Pour info, ton message a bien passé malgré Pinochet :-)
Ah pas évident la progr. parallèle.
Non, les journaliste font les perroquets des fabricants de CPU et ne réfléchissent pas à ce qu'ils disent. Selon des statistiques publiées à l'époque par... je ne sais plus qui... Les programmes confiés à des machines comme le Cray n'arrivaient à utiliser que 15% des performances théoriques de vectorisation de ce genre de machine... Après une année d'optimisation du code. On a fait des progrès avec des librairies de traitement matriciel écrites spécialement pour tirer parti des systèmes multi-units (ALU, FPU, CUDA, etc.), mais ça reste très spécifique et limité.
L'un des problèmes de multi-threading en calcul est l'accès concurrent à des zones de mémoire communes. Y'a pas de solution... à moins d'avoir un compilateur qui pourrait séparer ces zones, qu'il faudrait identifier à la compilation ou avec "profile"... Et ensuite répartir ces zones dans différentes "banc" de RAM... C'est très compliqué et c'est spécifique à chaque machine !
1. utilisation bureautique. max 5 coeurs sont utilisés en simultané, CPU idle la plupart du temps.
Oui, en effet. Mais c'est sans doute l'une des situation où l'on arrive à tirer le mieux parti des CPUs multi-coeurs.
2. utilisation multimedia
Oui, mais là je ne vois pas un vrai avantage d'avoir du multi-coeur. D'autant que pour le 3D et le Raytracing il y a déjà des librairies adaptées pour les différents GPUs. Pour visionner un film... A part le décodage déjà optimisé avec des fonctions dans les CPU/GPU, je ne vois pas.
3. compilation
Oui, il existe une version parallélisable de gcc : https://gcc.gnu.org/wiki/ParallelGcc
concernant le multimedia et le numcomp, regardez intel ISPC, c'est un C augmenté dans le même paradigme que les shaders opengl ou vulkan, pour faire du SIMD et multithreading automatisé, c'est top, le reste intégralement de la m.... à côté mais c'est un certain investissement en terme d'apprentissage, pas sur la syntaxe, mais la sémantique de ce langage.
Je ne fais plus ce genre d'exercice depuis longtemps. Ça prend énormément de temps et ton code se trouve attaché à une architecture très spécifique. De plus, on retombe sur le problème lié aux zones mémoire communes qui ne peuvent pas tirer parti des multi-canaux d'accès à la RAM et se retrouvent à faire la queue sur un seul canal.
c'est en ça qu'il important d'avoir une TDP de base faible, les conséquences du point 1.
Exact !
(difficile d'éviter le frenglish dans nos domaines de l'informatique.. :)
Oui... j'essaie mais certains termes Français sont encore plus ridicules (bogue... !)
dc _______________________________________________ gull mailing list [email protected] https://forum.linux-gull.ch/mailman/listinfo/gull
