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 _______________________________________________ gull mailing list gull@forum.linux-gull.ch https://forum.linux-gull.ch/mailman/listinfo/gull
