[gull] [SPAM] Re: [SPAM] naaan c'est pas de la pub pour *ntel outside!

[Daniel Cordey]

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