[gull] [SPAM] Re: [SPAM] naaan c'est pas de la pub pour *ntel outside!
Daniel Cordey
dc at pxcluster.com
Sun Jan 22 11:25:40 CET 2023
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
More information about the gull
mailing list