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

[Daniel Cordey]

Le 22.01.23 à 12:04, Philippe Strauss via gull a écrit :
> Au contraire il me semble que c'est bien la bureautique qui bénéficie le 
> moins des multicore, pour preuve intel et ses performance core contre 
> efficiency core.
> mais sous linux il n'y en a pas réélement besoin, libreoffice est pas 
> bien gourmand.

Oui, je ne vois pas l'utilité de paralléliser l'écriture de document 
texte ou autre :-)

> je connais pas le domaine de la base de donnée de ce côté, si ce n'est 
> (ne sont) quelques datastructures parallélisable sans locking en mémoire.

Ca dépend des "moteurs". Certains sont "threaded", d'autre en 
multi-process. La clef réside encore dans la manière de partager les 
informations entres les différents process/threads. C'est la même chose 
pour les serveurs Web. Dans le cas de *wsgi, tu as le choix entre 
multi-process ou multi-threading, ou encore une combinaison des deux. 
Mais, comme, encore et toujours, c'est un problème d'accès mémoire qui 
va limiter l'avantage des CPUs multi-coeurs. Il y a d'ailleurs plein 
d'articles au sujet du goulot d'étranglement de l'accès à la mémoire sur 
le site de netxplatform. Il y a aussi de gros débats au sujet de ces 
accès, admettant finalement que DDR* a une limite et qu'il faut 
envisager autre chose car le monde réalise enfin que le véritable frein 
à l'amélioration des performances ne réside pas dans des CPUs plus 
puissant (contrairement à ce que nous vendent les constructeurs).

Depuis le début on a eu "l'unité centrale" et la mémoire. Or, maintenant 
c'est une erreur. La masse de données est telle que l'on doit renverser 
ce paradigme et penser que le centre est représenté par les données et 
que l'on doit cesser de penser "déplacement" des donnés RAM/SSD <-> CPU. 
Les données ne doivent plus bouger et c'est la puissance de calcul qui 
doit se déplacer. C'est surtout vrai pour les data-center et les 
serveurs de base de données. Plutôt que d'avoir des DB serveurs que l'on 
interroge et un transfert des données (utilisant le réseau) vers les 
serveurs de traitement, il faut laisser les données dans les data-center 
et envoyer l'ordre d'exécution du code plus proche des DB serveurs. A la 
fin, on finira par comprendre que l'on doit avoir des ALU dans les chips 
mémoire; ce qui nous permettra d'accélérer massivement le traitement des 
données. Couplé à de mmap ça peut être d'enfer. Mais tout ça est de la 
musique d'avenir et on en est encore à subir le marketing des fabricants 
qui sont dans l'impasse et nous imposent leurs solutions inefficaces.

https://www.nextplatform.com/2022/04/06/the-hbm3-roadmap-is-just-getting-started/
https://www.nextplatform.com/2022/08/22/the-expanding-cxl-memory-hierarchy-is-inevitable-and-good-enough/
https://www.nextplatform.com/2023/01/18/what-do-we-do-when-compute-and-memory-stop-getting-cheaper/
https://www.nextplatform.com/2022/07/05/the-future-of-system-memory-is-mostly-cxl/
https://www.nextplatform.com/2021/03/11/its-time-to-start-paying-attention-to-vector-databases/
etc.

Bonne lecture :-)

dc