Euh non je ne travaille pas dans le secteur des CPU, mes connaissances dans le domaine viennent surtout des manuels d'optimisation d'Ulrich Drepper et d'Agner Fog et du suivi de l'architecture des CPU x86 pour l'optimisation.
De ce que j'en vois, pour le HPC selon les calculs il y en a qui sont plutôt intensifs en calcul, d'autre en accès mémoire.
Pour ceux qui sont intensifs en calculs, il est raisonnable d'équilibrer les différentes étapes (schématiquement, récupération des instructions, décodage, exécution (dans différentes unités) et utilisation des résultats).
Pour ceux qui sont intensifs en mémoire, outre un peu de logique (comme le write-combining, éventuellement accessible par des instructions spécialisées pour les CPU) l'amélioration a essentiellement consisté à intégrer le contrôleur mémoire au sein du CPU, ce qui a occasionné une réduction des latences vers la mémoire (fréquence supérieure, proximité physique avec les cœurs) et une meilleure gestion des systèmes multi-sockets (plusieurs contrôleurs mémoire largement indépendants, chaque socket a son accès à sa mémoire).
Pour l'amélioration des débits mémoire, il n'y a pas de grande révolution : amélioration de la fréquence de la mémoire, ou des générations qui doublent la quantité de données transmises par cycle d'horloge (largeur de bus notamment), au prix d'une augmentation de la latence en cycles), améliorations sur les cache du CPU.
J'ai vu tourner certains codes pour CPU (pourtant bien chiadés) dont la performance était exactement proportionnelle à la fréquence mémoire, à CPU fixé, parce qu'ils dépendaient purement de la latence. Pour ces codes, la mémoire graphique serait mauvaise vu qu'elle a des timings assez élevés (bien qu'en débit mémoire elle puisse monter plus haut que la DDR). Dans une carte graphique, les latences mémoires sont moins importantes que pour un CPU vu que comme me l'a répondu Jérôme Glisse, on les masque avec du multithreading (ce qui est possible car un GPU fait beaucoup de calculs similaires) https://linuxfr.org/news/kalray-un-processeur-massivement-parallele-tres-impressionnant-qu-il-est-loin-le-temps-de-mon-zx81#comment-1511777
Dans tous les cas, pour le code qui sera finalement exécuté et du point de vue du fondeur de CPU "généraliste", un déséquilibre entre les différentes unités d'exécution du CPU signifiera soit des performances moindres pour certains types de calculs purs, soit un investissement inutile dans l'optimisation d'une partie du CPU.
Donc la PS4 semble idéale pour des jeux (traitement des textures il me semble) ou d'autres applications gourmandes en bande passante mémoire, mais serait mauvais pour un code qui souffrirait d'une mauvaise latence mémoire (on trouve des benchmarks qui montrent que la GDDR5 a une latence 8 fois pire que la DDR3 par exemple).
Concernant ARM, j'imagine sans savoir qu'ils veulent rester aussi RISC que possible (en ajoutant des instructions SIMD cela dit) afin de diminuer les coûts de conception et le poids de l'histoire (support des vieilles instructions). Il me semble qu'ils tirent pas mal parti du fait que tout est intégré dans une seule puce. Mais de même que le CPU Jaguar de la PS4 est suffisant pour des applications de jeu mais n'est pas un processeur puissant pour le calcul pur, de même la cible de marché des ARM consiste en des applications où la capacité de calcul requise est faible (mais l'efficacité importante).
Toutefois, il est possible que la simplicité des cœurs ARM facilite le regroupement de plusieurs cœurs sur une puce pour produire des processeurs hautes performances. Enfin j'imagine (complètement :-) que le développement des CPU x86, essentiellement par Intel, s'est fait plus dans l'optique "j'ai une base de code existante (Windows & applications), que doit-on améliorer dans le CPU pour le faire tourner plus vite ?" et un peu "à l'avenir, utilisez ces instructions spécifiques pour ces cas particuliers" (genre la vectorisation). ARM, d'un autre côté, c'est plutôt "tenez, voici un nouveau processeur, recompilez vos OS pour".
[^] # Re: Et les compilateurs?
Posté par khivapia . En réponse à la dépêche Kalray un processeur massivement parallèle très impressionnant : Qu’il est loin le temps de mon ZX81. Évalué à 4.
Euh non je ne travaille pas dans le secteur des CPU, mes connaissances dans le domaine viennent surtout des manuels d'optimisation d'Ulrich Drepper et d'Agner Fog et du suivi de l'architecture des CPU x86 pour l'optimisation.
De ce que j'en vois, pour le HPC selon les calculs il y en a qui sont plutôt intensifs en calcul, d'autre en accès mémoire.
Pour ceux qui sont intensifs en calculs, il est raisonnable d'équilibrer les différentes étapes (schématiquement, récupération des instructions, décodage, exécution (dans différentes unités) et utilisation des résultats).
Pour ceux qui sont intensifs en mémoire, outre un peu de logique (comme le write-combining, éventuellement accessible par des instructions spécialisées pour les CPU) l'amélioration a essentiellement consisté à intégrer le contrôleur mémoire au sein du CPU, ce qui a occasionné une réduction des latences vers la mémoire (fréquence supérieure, proximité physique avec les cœurs) et une meilleure gestion des systèmes multi-sockets (plusieurs contrôleurs mémoire largement indépendants, chaque socket a son accès à sa mémoire).
Pour l'amélioration des débits mémoire, il n'y a pas de grande révolution : amélioration de la fréquence de la mémoire, ou des générations qui doublent la quantité de données transmises par cycle d'horloge (largeur de bus notamment), au prix d'une augmentation de la latence en cycles), améliorations sur les cache du CPU.
J'ai vu tourner certains codes pour CPU (pourtant bien chiadés) dont la performance était exactement proportionnelle à la fréquence mémoire, à CPU fixé, parce qu'ils dépendaient purement de la latence. Pour ces codes, la mémoire graphique serait mauvaise vu qu'elle a des timings assez élevés (bien qu'en débit mémoire elle puisse monter plus haut que la DDR). Dans une carte graphique, les latences mémoires sont moins importantes que pour un CPU vu que comme me l'a répondu Jérôme Glisse, on les masque avec du multithreading (ce qui est possible car un GPU fait beaucoup de calculs similaires)
https://linuxfr.org/news/kalray-un-processeur-massivement-parallele-tres-impressionnant-qu-il-est-loin-le-temps-de-mon-zx81#comment-1511777
Dans tous les cas, pour le code qui sera finalement exécuté et du point de vue du fondeur de CPU "généraliste", un déséquilibre entre les différentes unités d'exécution du CPU signifiera soit des performances moindres pour certains types de calculs purs, soit un investissement inutile dans l'optimisation d'une partie du CPU.
Donc la PS4 semble idéale pour des jeux (traitement des textures il me semble) ou d'autres applications gourmandes en bande passante mémoire, mais serait mauvais pour un code qui souffrirait d'une mauvaise latence mémoire (on trouve des benchmarks qui montrent que la GDDR5 a une latence 8 fois pire que la DDR3 par exemple).
Concernant ARM, j'imagine sans savoir qu'ils veulent rester aussi RISC que possible (en ajoutant des instructions SIMD cela dit) afin de diminuer les coûts de conception et le poids de l'histoire (support des vieilles instructions). Il me semble qu'ils tirent pas mal parti du fait que tout est intégré dans une seule puce. Mais de même que le CPU Jaguar de la PS4 est suffisant pour des applications de jeu mais n'est pas un processeur puissant pour le calcul pur, de même la cible de marché des ARM consiste en des applications où la capacité de calcul requise est faible (mais l'efficacité importante).
Toutefois, il est possible que la simplicité des cœurs ARM facilite le regroupement de plusieurs cœurs sur une puce pour produire des processeurs hautes performances. Enfin j'imagine (complètement :-) que le développement des CPU x86, essentiellement par Intel, s'est fait plus dans l'optique "j'ai une base de code existante (Windows & applications), que doit-on améliorer dans le CPU pour le faire tourner plus vite ?" et un peu "à l'avenir, utilisez ces instructions spécifiques pour ces cas particuliers" (genre la vectorisation). ARM, d'un autre côté, c'est plutôt "tenez, voici un nouveau processeur, recompilez vos OS pour".