Pourquoi ne pas créer un gros cœur de processeur? [fermé]


25

Je ne comprends pas pourquoi les fabricants de CPU fabriquent des puces multicœurs. La mise à l'échelle de plusieurs cœurs est horrible, c'est très spécifique à l'application, et je suis sûr que vous pouvez souligner certains programmes ou codes qui fonctionnent très bien sur de nombreux cœurs, mais la plupart du temps, la mise à l'échelle est une ordure. C'est un gaspillage d'espace de filière de silicium et un gaspillage d'énergie.

Les jeux, par exemple, n'utilisent presque jamais plus de quatre cœurs. Les simulations scientifiques et d'ingénierie comme Ansys ou Fluent sont évaluées en fonction du nombre de cœurs du PC sur lequel il fonctionne, vous payez donc plus car vous avez plus de cœurs, mais l'avantage de plus de cœurs devient vraiment médiocre au-delà des 16 cœurs, mais vous avez ces 64 cœurs postes de travail ... c'est un gaspillage d'argent et d'énergie. Il vaut mieux acheter un radiateur de 1500 W pour l'hiver, beaucoup moins cher.

Pourquoi ne font-ils pas un CPU avec un seul gros noyau?

Je pense que s'ils faisaient un équivalent à un cœur d'un processeur à huit cœurs, ce cœur aurait une augmentation de 800% de l'IPC, donc vous obtiendriez les performances complètes dans tous les programmes, pas seulement ceux qui sont optimisés pour plusieurs cœurs. Plus d'IPC augmentent les performances partout, c'est un moyen fiable et simple d'augmenter les performances. Plusieurs cœurs n'augmentent les performances que dans un nombre limité de programmes, et la mise à l'échelle est horrible et peu fiable.


Les commentaires ne sont pas pour une discussion approfondie; cette conversation a été déplacée vers le chat . Toutes les conclusions tirées doivent être rééditées dans la question et / ou toute réponse.
Dave Tweed

Cet article pourrait vous intéresser: gotw.ca/publications/concurrency-ddj.htm
lvella

"mais l'avantage de plus de cœurs devient vraiment médiocre au-delà des 16 cœurs" Vous ne savez évidemment pas de quoi vous parlez. Croyez-moi, j'ai travaillé sur des processus qui tournent sur quelques dizaines de milliers de CPU. Il existe toute une classe de problèmes appelée "Embarrassingly parallelisable", où lancer plus de cœurs sur le problème fonctionne très bien.
Aron

Réponses:


93

Le problème réside dans l'hypothèse que les fabricants de processeurs peuvent simplement ajouter plus de transistors pour rendre un seul cœur de processeur plus puissant sans conséquence.

Pour que le CPU en fasse plus, vous devez planifier ce que cela implique de faire plus. Il y a vraiment trois options:

  1. Faire fonctionner le cœur à une fréquence d'horloge plus élevée - Le problème avec cela est que nous atteignons déjà les limites de ce que nous pouvons faire.

    La consommation d'énergie et donc la dissipation thermique augmentent avec la fréquence - si vous doublez la fréquence, vous doublez nominalement la dissipation de puissance. Si vous augmentez la tension, votre dissipation de puissance augmente avec le carré de tension.

    Les interconnexions et les transistors ont également des retards de propagation en raison de la nature non idéale du monde. Vous ne pouvez pas simplement augmenter le nombre de transistors et vous attendre à pouvoir fonctionner à la même fréquence d'horloge.

    Nous sommes également limités par du matériel externe - principalement de la RAM. Pour accélérer le processeur, vous devez augmenter la bande passante mémoire, soit en l'exécutant plus rapidement, soit en augmentant la largeur du bus de données.


  1. Ajouter des instructions plus complexes - Au lieu d'exécuter plus rapidement, nous pouvons ajouter un jeu d'instructions plus riche - des tâches courantes comme le chiffrement, etc. peuvent être renforcées dans le silicium. Plutôt que de prendre plusieurs cycles d'horloge pour calculer dans le logiciel, nous avons plutôt une accélération matérielle.

    Cela se fait déjà sur les processeurs CISC (Complex Instruction Set). Voir des choses comme SSE2, SSE3. Un seul cœur de processeur est aujourd'hui beaucoup plus puissant qu'un cœur de processeur d'il y a 10 ans, même s'il fonctionne à la même fréquence d'horloge.

    Le problème est que, lorsque vous ajoutez des instructions plus compliquées, vous ajoutez plus de complexité et agrandissez la puce. En conséquence, le processeur ralentit - les fréquences d'horloge disponibles diminuent à mesure que les délais de propagation augmentent.

    Ces instructions complexes ne vous aident pas non plus dans les tâches simples. Vous ne pouvez pas durcir tous les cas d'utilisation possibles, donc inévitablement de grandes parties du logiciel que vous utilisez ne bénéficieront pas de nouvelles instructions et seront en fait affectées par la réduction de la fréquence d'horloge qui en résulte.

    Vous pouvez également augmenter la largeur des bus de données pour traiter plus de données à la fois, mais cela augmente encore le processeur et vous faites un compromis entre le débit obtenu via des bus de données plus grands et la baisse de la fréquence d'horloge. Si vous ne disposez que de petites données (par exemple des entiers 32 bits), avoir un processeur 256 bits ne vous aide pas vraiment.


  1. Rendre le CPU plus parallèle - Plutôt que d'essayer de faire une chose plus rapidement, faites plutôt plusieurs choses en même temps. Si la tâche que vous effectuez se prête à fonctionner sur plusieurs choses à la fois, alors vous voulez soit un processeur unique qui peut effectuer plusieurs calculs par instruction (Single Instruction Multiple Data (SIMD)), soit avoir plusieurs processeurs qui peuvent chacun effectuer un calcul.

    C'est l'un des principaux pilotes des processeurs multicœurs. Si vous avez plusieurs programmes en cours d'exécution ou si vous pouvez diviser votre programme unique en plusieurs tâches, avoir plusieurs cœurs de processeur vous permet de faire plus de choses à la fois.

    Étant donné que les cœurs de processeur individuels sont en réalité des blocs séparés (sauf les caches et les interfaces mémoire), chaque cœur individuel est plus petit que le cœur monolithique équivalent. Le cœur étant plus compact, les délais de propagation diminuent et vous pouvez exécuter chaque cœur plus rapidement.

    Quant à savoir si un programme unique peut bénéficier de plusieurs cœurs, cela dépend entièrement de ce que fait ce programme et de la façon dont il a été écrit.


Les commentaires ne sont pas pour une discussion approfondie; cette conversation a été déplacée vers le chat . Toutes les conclusions tirées doivent être rééditées dans la question et / ou toute réponse.
Dave Tweed

L'un des points soulevés dans les commentaires qui n'a toujours pas été abordé est que les CPU peuvent être parallèles en exécutant plusieurs instructions par horloge (Superscalar). C'est orthogonal à SIMD et à la fréquence; les instructions par horloge (IPC) sont le troisième facteur du débit réel par heure. Tous les processeurs modernes pour les charges de travail à utilisation interactive ont une largeur d'au moins 2.
Peter Cordes


37

En plus des autres réponses, il y a un autre élément: le rendement des puces . Un processeur moderne contient plusieurs milliards de transistors, chacun de ces transistors doit fonctionner parfaitement pour que la puce entière fonctionne correctement.

En créant des processeurs multicœurs, vous pouvez partitionner proprement des groupes de transistors. Si un défaut existe dans l'un des cœurs, vous pouvez désactiver ce cœur et vendre la puce à un prix réduit en fonction du nombre de cœurs fonctionnels. De même, vous pouvez également assembler des systèmes à partir de composants validés comme dans un système SMP.

Pour pratiquement tous les processeurs que vous achetez, il a commencé à devenir un modèle haut de gamme haut de gamme pour cette gamme de processeurs. Ce que vous vous retrouvez dépend des parties de cette puce qui ne fonctionnent pas correctement et qui sont désactivées. Intel ne fabrique aucun processeur i3: ils sont tous défectueux i7, avec toutes les fonctionnalités qui séparent les gammes de produits désactivées car elles ont échoué aux tests. Cependant, les portions qui fonctionnent encore sont toujours utiles et peuvent être vendues pour beaucoup moins cher. Tout pire devient des bibelots de porte-clés.

Et les défauts ne sont pas rares. La création parfaite de ces milliards de transistors n'est pas une tâche facile. Si vous n'avez pas la possibilité d'utiliser de manière sélective des portions d'une puce donnée, le prix du résultat va augmenter très rapidement.

Avec un seul processeur über, la fabrication est tout ou rien, ce qui entraîne un processus beaucoup plus coûteux. Pour certains appareils, comme les capteurs d'image à des fins scientifiques ou militaires, où vous avez besoin d'un énorme capteur et tout cela doit fonctionner, les coûts de ces appareils sont si énormes que seuls les budgets au niveau de l'État peuvent les payer.


4
Si / lorsque les rendements s'améliorent et produisent plus de puces pleinement fonctionnelles que les demandes du marché, les fournisseurs commencent généralement à fusionner certains cœurs / cache et / ou à les regrouper à une fréquence SKU plus basse, au lieu d'ajuster la structure de prix pour rendre le puces d'extrémité relativement moins chères. Avec les GPU / cartes graphiques, vous pouviez auparavant déverrouiller les unités de shader désactivées sur certaines cartes avec un piratage de micrologiciel, pour voir si vous aviez de la chance et une carte où elles n'étaient désactivées que pour la segmentation du marché, pas pour des défauts réels.
Peter Cordes

4
Intel a fabriqué des matrices à double cœur pour certaines de leurs puces. Avec toutes leurs références mobiles ULV (tension ultra-basse) étant à double cœur, il n'y avait pas assez de quatre cœurs défectueux, et la plus petite zone de matrice (en particulier avec un iGPU coupé également) donne plus de puces à double cœur fonctionnelles par tranche que de fusionner des matrices quadricœurs. en.wikichip.org/wiki/intel/microarchitectures/… a des découpes de Sandybridge de 131 mm² de taille de puce dual-core + graphiques GT1, contre 149 mm² dual-core + graphiques GT2 + 216 mm² quad + GT2. Il y a encore de la place pour des défauts dans le cache, etc.
Peter Cordes

Et (certains) défauts d'une partie d'une unité FMA peuvent probablement être traités en la fusionnant et en la vendant comme une puce Celeron ou Pentium (pas d'AVX, donc seulement des vecteurs 128 bits.) Même les puces Skylake ou Coffee Lake Pentium modernes manquent d'AVX . Les unités SIMD FMA représentent une fraction décente d'un cœur (et exécutent de nombreuses opérations SIMD autres que les mathématiques FP, y compris le mul entier et le décalage entier), donc je ne serais pas surpris si les unités FMA 2x 256 bits peuvent être mappées sur 2x 128 bits en utilisant les 2 morceaux qui fonctionnent toujours. Avec Skylake Xeon, il existe même des références avec un débit FMA AVX512 réduit (seulement 1 FMA 512 bits fonctionnel)
Peter Cordes

@PeterCordes Si les rendements deviennent aussi bons, les fournisseurs proposeront des conceptions de fréquence d'horloge plus denses et / ou plus rapides (et donc de taux de défauts plus élevés) jusqu'à ce que les taux de défauts reviennent à l'endroit où ils peuvent désactiver les cœurs et / ou sous-cadencer les puces. à vendre à rabais ..
Monty Harder

@MontyHarder: C'est un peu vrai, mais la validation coûte de l'argent et du temps, et les lignes de production existantes continueront de créer des conceptions existantes pendant un certain temps. Mais oui, certains exemples d'Intel de ce dont vous parlez sont Haswell Refresh , et divers raffinements de Skylake sans pratiquement aucun changement architectural et des améliorations mineures à leur processus de 14 nm. (Parfois avec un nouvel iGPU). par exemple Kaby Lake puis Coffee Lake etc. comme étapes "d'optimisation" dans la cadence normale de tick-tock d'Intel.
Peter Cordes

26

Dépendance aux données

Il est assez facile d'ajouter plus d'instructions par horloge en agrandissant une puce - c'est l'approche "SIMD". Le problème est que cela n'aide pas la plupart des cas d'utilisation.

Il existe environ deux types de charge de travail, indépendants et dépendants. Un exemple de charge de travail indépendante pourrait être "étant donné deux séquences de nombres A1, A2, A3 ... et B1, B2, ... etc, calculer (A1 + B1) et (A2 + B2) etc." Ce type de charge de travail est observé en infographie, traitement audio, apprentissage automatique, etc. Une grande partie de cela a été donnée aux GPU, qui sont spécialement conçus pour le gérer.

Une charge de travail dépendante peut être «Étant donné A, ajoutez-en 5 et recherchez-le dans un tableau. Prenez le résultat et ajoutez-y 16. Recherchez-le dans un autre tableau.

L'avantage de la charge de travail indépendante est qu'elle peut être divisée en de nombreuses parties différentes, donc plus de transistors y contribuent. Pour les charges de travail dépendantes, cela n'aide pas du tout - plus de transistors ne peuvent que le ralentir . Si vous devez obtenir une valeur de la mémoire, c'est un désastre pour la vitesse. Un signal doit être envoyé à travers la carte mère, se déplaçant sous la vitesse de la lumière, la DRAM doit charger une rangée et attendre le résultat, puis le renvoyer complètement. Cela prend des dizaines de nanosecondes. Ensuite, après avoir fait un calcul simple, vous devez envoyer pour le prochain.

Gestion de l'alimentation

Les cœurs de rechange sont désactivés la plupart du temps. En fait, sur un grand nombre de processeurs, vous ne pouvez pas exécuter tous les cœurs tout le temps sans que la chose prenne feu, le système les éteindra ou les synchronisera pour vous.

La réécriture du logiciel est la seule voie à suivre

Le matériel ne peut pas convertir automatiquement les charges de travail dépendantes en charges de travail indépendantes. Le logiciel non plus. Mais un programmeur qui est prêt à repenser son système pour tirer parti de nombreux cœurs pourrait bien le faire.


2
Citation nécessaire pour "ne peut pas exécuter tous les cœurs en même temps". À moins que vous ne considériez la vitesse d'horloge turbo maxi monocœur comme la "vraie" vitesse d'horloge du CPU. Dans le sens classique (avant d'atteindre le mur de puissance et la vitesse d'horloge était limitée par les retards de propagation du chemin critique), oui c'est vrai, mais dans le monde moderne, il est plus logique de considérer la vitesse d'horloge de base comme ce qui peut être maintenu avec tous cœurs actifs exécutant de lourdes charges de travail. Tout ce qui est supérieur à cela est de la sauce que vous pouvez utiliser de manière opportuniste en fonction des limites de puissance / thermique. (par exemple Turbo d'Intel).
Peter Cordes

1
Mais en termes de puissance, même l'horloge maximale d' un seul cœur est limitée par des thermiques plus importantes que les retards de propagation (bien que probablement les limites de l'étage du pipeline soient sélectionnées de sorte que vous êtes proche de cette limite au turbo max cible). Et la tension est également une variable: une puissance plus faible mais des retards de grille plus courts. Donc, de toute façon, cela n'a pas de sens de considérer le turbo max monocœur comme quelque chose que vous "devriez" pouvoir exécuter tous les cœurs, car cette limite vient déjà de la puissance.
Peter Cordes

Le contexte de la question d'origine posait définitivement la question de la vitesse maximale à cœur unique et, à de nombreuses fins pratiques, qui (et ses erreurs de cache) sont le véritable facteur limitant de la vitesse perçue par l'utilisateur.
pjc50

Oui, nous prendrions tous des performances monofil 8x au lieu d'un processeur 8 cœurs si nous le pouvions. (Avec SMT pour le laisser exécuter des charges de travail naturellement distinctes sans surcharge de changement de contexte. Voir ma réponse. :) Un noyau hyper-large hypothétique serait probablement en mesure de se synchroniser plus rapidement lorsque la charge de travail a causé beaucoup de blocages, au lieu de garder tout les transistors des unités SIMD FMA sont alimentés et commutent à chaque horloge. (Le découpage de puissance dans un seul cœur est également essentiel pour ne pas fondre à des horloges élevées; en.wikipedia.org/wiki/Dark_silicon ). Donc, avoir un seul cœur large ne ferait pas la différence.
Peter Cordes

Bien que vous ayez un point de vue que les performances à un seul thread que nous voyons sur les processeurs actuels sont meilleures que si elles étaient limitées à une vitesse d'horloge qu'ils pourraient soutenir simultanément sur tous les cœurs, même avec une charge de travail dans le pire des cas. c'est-à-dire que Turbo est essentiel, en particulier pour les pièces à faible TDP comme les puces pour ordinateur portable ( pourquoi mon processeur ne peut-il pas maintenir des performances de pointe dans HPC ): généralement un grand rapport entre la base et le turbo max, contrairement aux puces de bureau haute puissance mais à faible nombre de cœurs Par exemple, i7-6700k Skylake est à 4 GHz de base, 4,2 GHz à simple cœur turbo (sans overclocking; plus élevé est possible avec 95 W TDP).
Peter Cordes

20

En remontant dans le temps, les processeurs ne pouvaient pas fonctionner aussi rapidement. Par conséquent, si vous vouliez faire plus de traitement, vous aviez besoin de plus de processeurs. Cela pourrait être avec un coprocesseur mathématique, ou tout simplement avec plus du même processeur. Le meilleur exemple de ceci est le Transputer Inmos des années 80, qui a été spécifiquement conçu pour un traitement massivement parallèle avec plusieurs processeurs connectés ensemble. Tout le concept reposait sur l'hypothèse qu'il n'y avait pas de meilleur moyen d'augmenter la puissance de traitement que d'ajouter des processeurs.

Le problème est que cette hypothèse était (temporairement) incorrecte. Vous pouvez également obtenir plus de puissance de traitement en faisant effectuer par un processeur plus de calculs. Intel et AMD ont trouvé des moyens d'augmenter encore plus la vitesse d'horloge, et comme vous le dites, il est beaucoup plus facile de tout garder sur un seul processeur. Le résultat a été que jusqu'au milieu des années 2000, le processeur monocœur rapide était propriétaire du marché. Inmos est décédé au début des années 90, et toute leur expérience est morte avec eux.

Mais les bons moments devaient finir. Une fois que les vitesses d'horloge ont atteint le GHz, il n'y avait vraiment plus de possibilité d'aller plus loin. Et nous sommes revenus à plusieurs cœurs. Si vous ne pouvez vraiment pas aller plus vite, plus de cœurs sont la réponse. Comme vous le dites cependant, il n'est pas toujours facile d'utiliser efficacement ces cœurs. Nous sommes beaucoup mieux ces jours-ci, mais nous sommes encore loin de le rendre aussi facile que le Transputer.

Bien sûr, il existe d'autres options d'amélioration - vous pourriez être plus efficace à la place. SIMD et jeux d'instructions similaires effectuent plus de traitement pour le même nombre de tics d'horloge. Le DDR permet à vos données d'entrer et de sortir du processeur plus rapidement. Tout cela aide. Mais en ce qui concerne le traitement, nous sommes à nouveau dans les années 80 et les cœurs multiples.


Les commentaires ne sont pas pour une discussion approfondie; cette conversation a été déplacée vers le chat . Toutes les conclusions tirées doivent être rééditées dans la question et / ou toute réponse.
Dave Tweed

20

Bonne question, ou au moins une avec une réponse intéressante. Une partie de cette réponse représente un monde où les processeurs pourraient évoluer efficacement en largeur plutôt qu'avec plusieurs cœurs séparés. Les modèles de licence / prix seraient différents!

Le reste explique pourquoi ils ne le peuvent pas. Sommaire:

  • Le coût de plusieurs cœurs évolue de façon presque linéaire
  • Le coût de l'élargissement des échelles du pipeline superscalaire à 1 cœur ~ quadratique Cela est possible avec suffisamment de force brute, jusqu'à un certain point de toute façon. Les performances à un seul thread sont très importantes pour une utilisation interactive (la latence de bout en bout, pas seulement le débit), donc les processeurs haut de gamme à gros cœurs actuels paient ce prix. par exemple Skylake (4 larges), Ryzen (5 ou 6 larges) et Apple A12 (7 larges pour les gros cœurs, 3 larges pour les petits cœurs éconergétiques)
  • Une baisse sérieuse des rendements IPC en élargissant simplement le pipeline au-delà de 3 ou 4, même avec une exécution dans le désordre pour trouver l' ILP . Les échecs de branchement et les échecs de cache sont difficiles et bloquent tout le pipeline.
  • Vous n'avez pas mentionné la fréquence, juste l'IPC, mais la fréquence de mise à l'échelle est également difficile. Une fréquence plus élevée nécessite une tension plus élevée, donc la puissance évolue avec une fréquence au cube : à ^1partir de la fréquence directement et ^2de la tension. (Le condensateur stocke des échelles d'énergie avec V ^ 2, et la majeure partie de la puissance dynamique au-delà du courant de fuite provient de la charge de pompage dans les charges capacitives des portes FET + fils.)

    Performance = fréquence multipliée par IPC. (Dans la même architecture. Un SIMD plus large vous permet de faire le même travail avec moins d'instructions, et certaines ISA sont plus denses que d'autres, par exemple, MIPS prend souvent plus d'instructions pour faire le même travail que x86 ou AArch64.)

Les coûts sont liés à la filière (coût de fabrication) et / ou à l'énergie (ce qui limite indirectement la fréquence car le refroidissement est difficile). En outre, la réduction de la puissance et des performances par Watt est un objectif en soi, en particulier pour les mobiles (batteries) et les serveurs (densité de puissance / coûts de refroidissement / coûts d'électricité).

Avant que le multi-core par socket ne soit une chose, vous aviez des systèmes multi-socket pour des cas d'utilisation haut de gamme où vous vouliez plus de débit que ce qui était réalisable avec un seul processeur qui pouvait être fabriqué, donc c'était les seuls systèmes SMP. (Serveurs, postes de travail haut de gamme).

Si un seul cœur pouvait évoluer aussi efficacement que vous le souhaitiez, nous aurions des systèmes avec 1 cœur physique par socket et SMT (par exemple HyperThreading) pour les laisser agir comme plusieurs cœurs logiques. Les ordinateurs de bureau / portables classiques n'auraient qu'un seul cœur physique, et nous n'aurions pas de mal à paralléliser des choses qui ne évoluent pas linéairement avec plus de cœurs. par exemple make -j4pour profiter des serveurs multi-socket et / ou pour masquer la latence d'E / S sur un bureau. (Ou peut-être que nous essaierions toujours de paralléliser beaucoup si la largeur du pipeline évoluait facilement mais IPC ne le faisait pas, nous avons donc dû utiliser plus de threads SMT.) Votre noyau de système d'exploitation devrait toujours fonctionner sur tous les cœurs logiques, à moins que présente SMT à l'OS était très différent, donc des algorithmes de programmation et de verrouillage parallèles y seraient encore nécessaires.


Donald Knuth a déclaré dans une interview en 2008

Je pourrais tout aussi bien exprimer un peu mon mécontentement personnel face à la tendance actuelle à l'architecture multicœur. Pour moi, il semble plus ou moins que les concepteurs de matériel sont à court d'idées et qu'ils essaient de rejeter la responsabilité de la future disparition de la loi de Moore aux rédacteurs de logiciels en nous donnant des machines qui fonctionnent plus rapidement que sur quelques-uns. repères clés!

Oui, si nous pouvions avoir des processeurs monocœur miracles avec un débit 8 fois supérieur à de vrais programmes , nous les utiliserions probablement toujours. Avec les systèmes à double socket uniquement lorsque cela valait la peine de payer beaucoup plus pour plus de débit (pas de performances à un seul thread).

Plusieurs processeurs réduisent les coûts de changement de contexte lorsque plusieurs programmes sont en cours d'exécution (en les laissant réellement s'exécuter en parallèle au lieu de basculer rapidement entre eux); le multitâche préventif interrompant les énormes machines hors service dont un processeur aurait besoin serait probablement encore plus douloureux qu'aujourd'hui.

Physiquement, il s'agirait d'un seul cœur (pour une hiérarchie de cache simple sans interconnexion entre les cœurs) mais prendrait en charge SMT (par exemple, HyperThreading d'Intel) afin que le logiciel puisse l'utiliser comme 8 cœurs logiques qui rivalisent dynamiquement pour les ressources de débit. Ou lorsqu'un seul thread est en cours d'exécution / non bloqué, il en bénéficierait pleinement.

Donc, vous utiliseriez plusieurs threads lorsque cela serait plus facile / naturel (par exemple, des processus séparés s'exécutant simultanément), ou pour des problèmes facilement parallélisés avec des chaînes de dépendance qui empêcheraient de maximiser l'IPC de cette bête.

Mais malheureusement, c'est un vœu pieux de la part de Knuth que les processeurs multicœurs cessent jamais d'être une chose à ce stade.


Mise à l'échelle des performances sur un seul thread

Je pense que s'ils faisaient un équivalent à 1 cœur d'un processeur à 8 cœurs, ce cœur aurait une augmentation de 800% de l'IPC afin que vous obteniez les performances complètes dans tous les programmes, pas seulement ceux qui sont optimisés pour plusieurs cœurs.

Oui c'est vrai. S'il était possible de construire un tel processeur , ce serait très étonnant. Mais je pense que c'est littéralement impossible sur le même processus de fabrication de semi-conducteurs (c'est-à-dire la même qualité / efficacité des transistors). Ce n'est certainement pas possible avec le même budget de puissance et la même zone de matrices qu'un processeur à 8 cœurs, même si vous économisez de la logique pour coller les cœurs ensemble, et n'auriez pas besoin d'autant d'espace pour les caches privés par cœur.

Même si vous autorisez des augmentations de fréquence (puisque le véritable critère est le travail par seconde, pas le travail par horloge), rendre même un processeur 2x plus rapide serait un énorme défi.

S'il était possible à peu près à la même puissance et au même budget (donc le coût de fabrication) de construire un tel processeur, oui, les fournisseurs de CPU les construiraient déjà de cette façon.

Voir Microprocesseurs modernes Un guide de 90 minutes!

Plus précisément les noyaux plus ou plus larges? section, pour le contexte nécessaire pour comprendre cette réponse; cela commence simplement par le fonctionnement des processeurs pipelinés dans l'ordre, puis superscalaire (plusieurs instructions par horloge). Explique ensuite comment nous avons atteint le mur de puissance à l'époque de P4, ce qui a conduit à la fin de la mise à l'échelle facile des fréquences, ne laissant principalement que l'IPC et plus de travail par instruction (par exemple SIMD) comme voie à suivre, même avec des transistors plus petits.

Rendre un pipeline plus large (instructions max par horloge) a généralement un coût en largeur au carré . Ce coût est mesuré en zone de matrice et / ou en puissance, pour une vérification de dépendance parallèle plus large (détection des dangers), et un planificateur hors service plus large pour trouver des instructions prêtes à exécuter. Et plus de ports de lecture / écriture sur votre fichier de registre et cache si vous souhaitez exécuter des instructions autres que nop. Surtout si vous avez des instructions à 3 entrées comme FMA ou add-with-carry (2 registres + drapeaux).

Il y a également des rendements IPC décroissants pour élargir les CPU ; la plupart des charges de travail ont un ILP (Instruction-Level Parallelism) limité à petite échelle / courte portée pour les CPU à exploiter, donc élargir le cœur n'augmente pas IPC (instructions par horloge) si IPC est déjà limité à moins que la largeur de la noyau par des chaînes de dépendance, des échecs de branche, des échecs de cache ou d'autres décrochages. Bien sûr, vous obtiendrez une accélération dans certaines boucles déroulées avec des itérations indépendantes, mais ce n'est pas ce que la plupart du code passe la plupart de son temps à faire. Les instructions de comparaison / branchement représentent 20% de la combinaison d'instructions en code "typique", IIRC. (Je pense que j'ai lu des chiffres de 15 à 25% pour divers ensembles de données.)

En outre, un échec de cache qui bloque toutes les instructions dépendantes (puis tout une fois que la capacité ROB est atteinte) coûte plus cher pour un processeur plus large. (Le coût d'opportunité de laisser plus d'unités d'exécution inactives; plus de travail potentiel ne se fait pas.) Ou un échec de branche provoque également une bulle.

Pour obtenir 8 fois l'IPC, nous aurions besoin d'au moins 8 fois l'amélioration de la précision de la prédiction de branche et des taux d'accès au cache . Mais les taux d'accès au cache n'évoluent pas bien avec la capacité du cache au-delà d'un certain point pour la plupart des charges de travail. Et la pré-récupération HW est intelligente, mais ne peut pas être aussi intelligente. Et à 8x l'IPC, les prédicteurs de branche doivent produire 8x autant de prédictions par cycle et les rendre plus précises.


Les techniques actuelles de construction de CPU d'exécution hors ordre ne peuvent trouver ILP que sur de courtes plages . Par exemple, la taille ROB de Skylake est de 224 uops de domaine fusionné, le planificateur pour les uops non exécutés est de 97 domaine non fusionné. Voir Comprendre l'impact de lfence sur une boucle avec deux longues chaînes de dépendance, pour augmenter les longueurs dans le cas où la taille du planificateur est le facteur limitant pour extraire ILP de 2 longues chaînes d'instructions, si elles deviennent trop longues. Et / ou voir cette réponse plus générale et introductive ).

Donc, trouver ILP entre deux longues boucles distinctes n'est pas quelque chose que nous pouvons faire avec du matériel. La recompilation binaire dynamique pour la fusion de boucles pourrait être possible dans certains cas, mais les CPU durs et pas quelque chose peuvent vraiment faire à moins qu'ils ne choisissent la route Transmeta Crusoe. (Couche d'émulation x86 au-dessus d'un ISA interne différent; dans ce cas, VLIW). Mais les conceptions x86 modernes standard avec des caches uop et des décodeurs puissants ne sont pas faciles à battre pour la plupart des codes.

Et en dehors de x86, tous les ISA encore utilisés sont relativement faciles à décoder, il n'y a donc aucune motivation pour la recompilation dynamique autre que les optimisations à longue distance. TL: DR: espérer des compilateurs magiques qui peuvent exposer plus d'ILP au matériel n'a pas fonctionné pour Itanium IA-64 , et il est peu probable qu'il fonctionne pour un processeur super large pour tout ISA existant avec un modèle d'exécution en série.


Si vous aviez un processeur super large, vous voudriez certainement qu'il prenne en charge SMT afin que vous puissiez le nourrir avec du travail à faire en exécutant plusieurs threads à faible ILP.

Étant donné que Skylake a actuellement 4 uops de large (et atteint un véritable IPC de 2 à 3 uops par horloge, ou même plus proche de 4 dans le code à haut débit), un processeur hypothétique 8x plus large aurait une largeur de 32!

Être capable de sculpter cela en 8 ou 16 CPU logiques qui partagent dynamiquement ces ressources d'exécution serait fantastique: les threads non bloqués obtiennent toute la bande passante frontale et le débit back-end.

Mais avec 8 cœurs séparés, lorsqu'un thread se bloque, il n'y a rien d'autre pour alimenter les unités d'exécution; les autres fils n'en bénéficient pas.

L'exécution est souvent éclatante: elle s'arrête en attendant un chargement raté du cache, puis une fois que cela arrive, de nombreuses instructions en parallèle peuvent utiliser ce résultat. Avec un processeur ultra-large, cette rafale peut aller plus vite et peut réellement aider avec SMT.


Mais nous ne pouvons pas avoir de CPU magiques super larges

Donc, pour gagner du débit, nous devons plutôt exposer le parallélisme au matériel sous la forme d'un parallélisme au niveau des threads . Généralement, les compilateurs ne savent pas quand / comment utiliser les threads, sauf pour les cas simples comme les très grosses boucles. (OpenMP ou gcc -ftree-parallelize-loops). Il faut encore de l'habileté humaine pour retravailler le code afin de réaliser efficacement des travaux utiles en parallèle, car la communication entre les threads est coûteuse, tout comme le démarrage des threads.

Le TLP est un parallélisme à grain grossier, contrairement à l'ILP à grain fin dans un seul thread d'exécution que HW peut exploiter.


Les processeurs destinés à des charges de travail interactives (comme Intel / AMD x86 et les cœurs haut de gamme Apple / ARM AArch64) poussent certainement dans les rendements décroissants de la mise à l'échelle IPC, car les performances à un seul thread sont toujours si précieuses lorsque la latence est importante, pas seulement le débit pour problèmes massivement parallèles.

Pouvoir exécuter 8 copies d'un jeu en parallèle à 15fps chacune est beaucoup moins précieux que pouvoir exécuter une copie à 45fps. Les éditeurs de CPU le savent, et c'est pourquoi les CPU modernes utilisent une exécution dans le désordre même si cela coûte beaucoup d'énergie et de matrice. (Mais les GPU ne le font pas parce que leur charge de travail est déjà massivement parallèle).

Le matériel à plusieurs cœurs Xeon Phi d'Intel (Knight's Landing / Knight's Mill) est un point intéressant à mi-chemin: exécution hors service très limitée et SMT pour garder les cœurs à 2 larges alimentés avec des instructions SIMD AVX512 pour calculer les nombres. Les cœurs sont basés sur l'architecture Silvermont à faible consommation d'Intel. (Exécutif hors service mais avec une petite fenêtre de réorganisation, beaucoup plus petite que la famille Sandybridge à gros cœurs. Et un pipeline plus étroit.)


BTW, tout cela est orthogonal à SIMD. Faire plus de travail par instruction est toujours utile, si cela est possible pour votre problème.


Modèles de tarification

Les modèles de tarification des logiciels sont basés sur le paysage actuel du matériel.

Les modèles de licence par cœur sont devenus plus répandus (et pertinents même pour les postes de travail à socket unique) avec l'avènement des processeurs multicœurs. Avant cela, cela ne concernait que les serveurs et les grandes stations de travail.

Si le logiciel n'avait pas besoin de plusieurs cœurs pour fonctionner à vitesse maximale, il n'y aurait pas vraiment de moyen de le vendre moins cher aux personnes qui n'en tirent pas autant d'avantages car ils l'exécutent sur un processeur plus faible. À moins que l'écosystème logiciel / matériel n'ait évolué des contrôles sur les "canaux SMT" qui vous permettent de configurer une largeur d'exécution maximale pour le code s'exécutant sur ce noyau logique. (Encore une fois, imaginer un monde où les processeurs évoluent en largeur de pipeline au lieu de plusieurs cœurs séparés.)


2
"le démarrage des threads coûte cher" - ce n'est pas un fait difficile; c'est un artefact des systèmes d'exploitation modernes communs.
MSalters

1
@MSalters Et en effet, certains projets de recherche ont exploré à quel point il serait génial d'abandonner cette approche. Il en va de même pour «l'habileté humaine à retravailler le code» - il existe des façons d'écrire du code qui sont naturellement plus faciles à paralléliser, elles n'ont tout simplement pas été très populaires au cours des dernières décennies. Là où ils sont utilisés, vous pouvez généralement voir une mise à l'échelle horizontale massive à très faible coût; en fait, au point que la mise à l'échelle horizontale commence à devenir beaucoup moins chère que verticale dans de nombreuses applications. Cela signifie simplement que vous ne devez pas donner aux développeurs le choix - si les circonstances le forcent, cela fonctionne bien: D
Luaan

11

Permettez-moi de faire une analogie:

Si vous avez un singe en train de taper sur une machine à écrire et que vous voulez faire plus de frappe, vous pouvez donner du café au singe, des leçons de dactylographie et peut-être menacer de le faire fonctionner plus rapidement, mais il arrive un moment où le singe va taper à la capacité maximale.

Donc, si vous voulez faire plus de frappe, vous devez obtenir plus de singes.


Pour étendre l'analogie plus loin, vous avez besoin d'une machine à écrire distincte pour chaque singe (représentant le bus de données dont chaque noyau aura besoin), vous avez besoin d'un moyen d'obtenir des bananes pour chaque singe et de quelque chose pour ramasser leurs excréments (analogue à la distribution d'énergie et à la chaleur dissipation) et vous avez besoin d'un moyen pour vous assurer que les singes n'essaient pas tous de taper le même passage dans Twelfth Night (comme pour répartir correctement la charge de travail entre les processeurs). Mais tout cela est moins de travail pour plus de gain que d'essayer d'obtenir plus de frappe d'un singe.


7

Vous faites remarquer que beaucoup de logiciels n'utilisent pas plus de (x) cœurs. Mais c'est entièrement une limitation imposée par les concepteurs de ce logiciel. Les ordinateurs personnels ayant plusieurs cœurs sont encore nouveaux (ish) et la conception de logiciels multi-threads est également plus difficile avec les API et les langages traditionnels.

Votre PC n'exécute pas seulement ce programme. Il fait tout un tas d'autres choses qui peuvent être placées sur des cœurs moins actifs afin que votre logiciel principal ne soit pas autant interrompu par eux.

Il n'est actuellement pas possible d'augmenter simplement la vitesse d'un seul cœur pour correspondre au débit de 8 cœurs. Plus de vitesse devra probablement provenir de la nouvelle architecture.

Comme plus de cœurs sont couramment disponibles et que les API sont conçues avec cette hypothèse, les programmeurs commenceront généralement à utiliser plus de cœurs. Les efforts pour rendre les conceptions multithread plus faciles à réaliser se poursuivent. Si vous posiez cette question dans quelques années, vous diriez probablement "Mes jeux n'utilisent généralement que 32 cœurs, alors pourquoi mon processeur en a 256?".


3
La différence entre 1 et plusieurs cœurs est énorme en termes de mise à profit des logiciels. La plupart des algorithmes et programmes sont en série. Par exemple, Donald Knuth a déclaré que les processeurs multicœurs ressemblaient à des concepteurs de matériel informatique " essayant de rejeter la faute de la future disparition de la loi de Moore aux rédacteurs de logiciels en nous donnant des machines qui ne fonctionnent plus rapidement que sur quelques références clés! "
Peter Cordes

Malheureusement, personne n'a encore trouvé un moyen de faire en sorte qu'un seul cœur large / rapide exécute un programme monothread aussi rapidement que possible pour que du code efficacement parallèle soit exécuté sur plusieurs cœurs. Mais heureusement, les concepteurs de CPU se rendent compte que les performances à un seul thread sont toujours critiques et rendent chaque noyau individuel beaucoup plus grand et plus puissant qu'il ne le serait s'ils recherchaient un débit pur sur des problèmes parallèles. (Comparez un Skylake (4 de large) ou Ryzen (5 de large) vs un noyau d'un Xeon Phi (Knight's Landing / Knight's Mill basé sur Silvermont + AVX512) (2-large et limité OoO exec)
Peter Cordes

2
Quoi qu'il en soit, avoir au moins 2 cœurs est souvent utile pour un système d'exploitation multitâche, mais le multitâche préventif sur un seul cœur qui était 4x ou 8x aussi rapide qu'un processeur actuel serait assez bon. Pour de nombreux cas d'utilisation interactifs, ce serait beaucoup mieux, s'il était possible de construire du tout / avec le même budget de puissance. (Le double cœur aide à réduire les coûts de changement de contexte lorsque plusieurs tâches nécessitent du temps CPU, cependant.)
Peter Cordes

1
C'est vrai, mais historiquement multicœur était plus cher. Il n'y avait pas beaucoup de raisons de concevoir des algorithmes parallèles en dehors des applications scientifiques. Il y a beaucoup de place pour la parallélisation, même dans les algorithmes qui nécessitent une exécution principalement en série. Mais l'IPC de génération actuelle n'est pas génial et est facile à gâcher. Ce qui entraîne généralement des bogues très difficiles à trouver et à corriger. Bien sûr, un processeur 4x plus rapide serait incroyable (mais vous voudriez toujours plusieurs cœurs).
hekete

2
@PeterCordes Eh bien, la plupart des algorithmes et des programmes ne sont pas en série parce qu'ils doivent l' être, mais surtout parce que c'est la façon dont cela a toujours été fait (avec un saupoudrage de "c'était un bon compromis"). Les cas les plus flagrants sont ceux où vous pouvez simplement exécuter le même programme quatre fois sur quatre charges de travail distinctes et les exécuter en parallèle sans problème. Mais cela pose un autre problème - le CPU n'est pas souvent un goulot d'étranglement, et généralement le moyen de le contourner est d'utiliser de meilleurs algorithmes, pas plus de CPU. Parfois, ceux-ci aident également à d'autres goulots d'étranglement (mémoire, disque, réseau ...).
Luaan

3

La raison la plus convaincante d'un point de vue historique est la dissipation de puissance .

Après le Pentium IV, Intel a tenté de mettre au point un processeur de nouvelle génération nommé Tejas, censé fonctionner dans la plage de 4 GHz à 12 GHz. Le problème était que courir à cette vitesse générait trop de chaleur pour être viable.

Après l'annulation de Tejas, il a fallu à Intel 10 à 15 ans de plus pour que les cœurs tournent enfin à 4 GHz avec des niveaux de chaleur acceptables.

Voir Tejas et Jayhawk .

Intel avait un autre projet en parallèle avec Tejas qui impliquait l'utilisation de plusieurs cœurs. Ce projet avait des niveaux de chaleur acceptables, c'est ainsi qu'ils se sont déroulés. Cela leur a permis d'augmenter les performances maintenant plutôt que d'attendre encore 10 ans pour les processus de fabrication à 10 nm.

En supposant que les cœurs ne manquent pas de ressources, alors pour obtenir le même nombre d'instructions par seconde à partir d'un seul cœur au lieu de N cœurs, vous aurez besoin que le taux d'instruction de ce cœur unique soit N fois plus rapide. La dissipation dynamique de puissance d'un cœur de CPU est linéairement proportionnelle à la fréquence de fonctionnement. Il est également proportionnel au carré de la tension de fonctionnement. Le fonctionnement à des fréquences plus basses permet l'utilisation de tensions de fonctionnement plus faibles. L'utilisation de tensions plus faibles à des fréquences plus basses signifie que la chaleur générée, pratiquement, diminue avec le cube de la fréquence de fonctionnement.

Un exemple extrême de ceci est le cerveau humain, qui peut effectuer l'équivalent de 2 ^ 18 opérations par seconde en utilisant seulement 20 W de puissance. Il y parvient en utilisant des milliards de neurones fonctionnant en parallèle à seulement quelques centaines de Hz.

Gardez également à l'esprit qu'il existe généralement des centaines ou des milliers de threads exécutés simultanément sur un PC. Le système d'exploitation gère l'allocation de temps sur un noyau à chaque thread. Ainsi, même si un programme individuel ne tire pas parti de tous les cœurs, il en bénéficie quand même parce que les autres programmes prennent moins de temps CPU s'ils s'exécutent sur un autre cœur.

Si quoi que ce soit, le marché des hautes performances évolue vers un traitement plus parallèle sous la forme de FPGA. Intel a récemment acheté Altera (le deuxième plus grand fabricant de FPGA) et vend maintenant des cartes avec un accélérateur matériel FPGA. Le logiciel peut charger le FPGA avec une image au moment de l'exécution à l'aide d'un appel API. Le CPU alimente ensuite les données dans le FPGA et lui permet de faire la plupart du travail. Les types d'applications sont généralement l'encodage vidéo, l'IA, le rendu, la recherche dans la base de données, etc.


Gardez également à l'esprit qu'il existe généralement des centaines ou des milliers de threads exécutés simultanément sur un PC. Non, pas en cours d'exécution . Que de nombreux threads existent sur les ordinateurs de bureau modernes, mais presque tous dorment en attente d'E / S ou d'une minuterie à un moment donné. Par exemple, la moyenne de charge (au cours de la dernière minute) sur mon bureau Linux est actuellement de 0,19 tâche activement prête à utiliser le temps CPU à tout moment. Si j'exécutais un encodage vidéo, x264 aurait démarré plusieurs threads pour que le système d'exploitation puisse planifier sur plusieurs cœurs, mais seulement autant que j'ai de cœurs logiques.
Peter Cordes

Et BTW, l'OP (pour une raison quelconque) a complètement omis la fréquence et a demandé des informations sur la mise à l'échelle IPC (instructions par cycle d'horloge), pas par seconde. Ce que vous dites est vrai, mais ils proposaient d' élargir les CPU , et non de cadencer plus haut. J'ai déjà abordé cela dans ma réponse, donc votre réponse expliquant la mise à l'échelle de la puissance avec la fréquence est un bon ajout, +1.
Peter Cordes

@PeterCordes C'est exact, je ne voulais pas impliquer que tous les threads s'exécutent en même temps, bien sûr, ils se relaient. Merci de clarifier.
user4574

Et bien pas tant à tour de rôle qu’ils ne sont pas du tout prêts à courir, la plupart du temps. Ils sont pour la plupart tous endormis, ne se réveillant généralement que pour une courte rafale de calcul, par exemple après que le système d'exploitation a fourni une pression sur une touche ou une lecture réseau, ou les réveille en raison de l'expiration d'un temporisateur. Il est rare que plus de 2 personnes soient éveillées à la fois, à moins que vous ne fassiez quelque chose de calcul intensif. Et si vous l'êtes, vous ne démarrez pas des centaines de threads, vous démarrez un certain nombre de threads ~ = nombre de cœurs disponibles.
Peter Cordes

2

Juste pour compléter l'image de tout cela ...

Les réseaux de neurones et l'IA sont les sujets les plus brûlants du moment. L'une des raisons est que l'on peut utiliser efficacement un grand nombre de cœurs simples en parallèle et ainsi extraire des performances de calcul proches des maximales. L'exigence est intrinsèquement massivement parallèle et correspond assez facilement à un ensemble de processeurs sans beaucoup de communication entre les cœurs. C'est pourquoi les GPU ont été la première technologie goto pour l'accélération de l'IA. À l'heure actuelle, nous voyons des puces optimisées encore mieux que les GPU vidéo pour les NN qui arrivent sur le marché. L'étape suivante, ou peut-être finale, consiste à créer des NN en utilisant des technologies analogiques comme les memristors.

Et en passant, dans quelque chose comme un PC de jeu, il y a beaucoup plus de performances brutes dans la carte graphique que le processeur multicœur Intel ou AMD


2
Re "... intrinsèquement massivement parallèle" : même parallèle embarrassant ?
Peter Mortensen

1

Fondamentalement, les pertes CMOS sont exponentiellement (^ 1,5) proportionnelles à la fréquence et les performances CPU parallèles sont un peu moins que linéaires proportionnelles au nombre de CPU.

Ainsi, le rapport entre la puissance de calcul et la dissipation de puissance est amélioré pour les applications multi-CPU à différentes fréquences d'horloge lors de la comparaison de la vitesse et de la quantité de CPU pour une dissipation de puissance fixe.

C'est plus complexe que cela, mais ce sont les principes fondamentaux pour lesquels les processeurs parallèles sont meilleurs pour le Watt dans les applications dynamiques. Il y aura toujours des exceptions lors de l'optimisation pour un scénario.

Ce n'est pas la taille d'un processeur plus grand qui le rend plus rapide pour les applications PC typiques Intel / AMD, c'est plutôt la taille réduite de la résolution lithographique et de la capacité de grille inférieure qui réduit la puissance ainsi que le niveau de sous-seuil et la tension du cœur.

L'amélioration n'est pas linéaire et ne signifie pas que 8 cœurs est 4 fois mieux que 2, mais l'objectif si atteint est d'avoir plus de plage dynamique de traitement avec l'étranglement de la dissipation de puissance, de la vitesse et de la tension pour améliorer les performances et l'efficacité et la puissance de crête à la demande sans élévation excessive de la température.

Pour une réponse plus scientifique, lisez https://www.sciencedirect.com/topics/computer-science/dynamic-power-consumption


-2

Les multicœurs ne sont généralement pas multiscalaires. Et les cœurs multiscalaires ne sont pas multicœurs.

Ce serait une sorte de recherche parfaite d'une architecture multiscalaire fonctionnant à plusieurs mégahertz, mais en général, ses ponts ne seraient pas activés par le consommateur, mais coûteux, de sorte que la tendance est à la programmation multicœur à basse fréquence plutôt qu'aux instructions courtes à des vitesses d'horloge élevées.

Les cœurs d'instructions multiples sont moins chers et plus faciles à commander, et c'est pourquoi c'est une mauvaise idée d'avoir des architectures multiscalaires à plusieurs gigahertz.


1
Voulez-vous dire "superscalaire", plusieurs instructions par horloge? La plupart des processeurs multicœurs sont superscalaires. Par exemple, Ryzen a une largeur de 5. Les puces AArch64 haut de gamme d'Apple ont une largeur de 6 ou 8. Il y a beaucoup de fruits faciles à exploiter pour un processeur à 2 larges dans la plupart du code, il vaut donc la peine de faire chaque cœur au moins à 2 avant de passer à plusieurs cœurs qui ont chacun besoin de leur propre cache privé et d'une interconnexion entre les cœurs ( par exemple, les cartes de calcul à plusieurs cœurs Xeon Phi d'Intel ont de nombreux cœurs à double émission). Idem pour les cœurs de smartphone: les petits cœurs ont au moins 2 de large. La performance à un seul thread est importante!
Peter Cordes

1
Ou vouliez-vous dire dl.acm.org/citation.cfm?id=224451 - un document de recherche sur ce qu'ils appellent des cœurs "multiscalaires" qui recherchent l'ILP sur de plus grandes plages dans le graphique de flux de contrôle d'un programme de haut niveau, en utilisant une combinaison de HW et SW. Les processeurs traditionnels que nous utilisons dans les ordinateurs de bureau et les smartphones ne sont pas comme ça, ils sont juste superscalaires ordinaires avec une exécution dans le désordre, implémentant un ISA série qui prétend exécuter des instructions une par une.
Peter Cordes

Merci. afaik, l'idée derrière l'arche scalaire est la mesurabilité de la chaleur derrière des ensembles d'instructions connus ou prédéfinis (le cas d'AVX). <br/> Le calcul des architectures actuelles en fonction de la chaleur est considéré comme non prévisible par ordinateur. cela améliore l'improbabilité que les multicœurs pourraient fonctionner à de grandes fréquences car leur capacité à fonctionner dans un idéal temps / chaleur n'est pas calculable. c'est tout ce que je sais jusqu'à présent. je suis en train de creuser des machines vectorielles pour comprendre la physique des "multiscalaires". le cas est xeon / phy suivre une courbe thermique idéale comme le faisaient les anciens cpus. améliorer l'expérience client
machtur

Les jeux d'instructions SIMD comme AVX sont un moyen d'obtenir plus de travail grâce au pipeline sans avoir à élargir l'ensemble du pipeline, juste les unités d'exécution. Par exemple, Skylake peut exécuter 3 vpaddd ymm0, ymm1, ymm2instructions par horloge, chacune exécutant 8 ajouts d'entiers 32 bits compressés. Donc, 24 nombres entiers s'ajoutent par horloge, mais la machine d'exécution hors service ne doit "garder" que 3 instructions en vol. C'est beaucoup moins cher à construire qu'un CPU qui pourrait exécuter 24 add eax, edxinstructions par horloge. SIMD est fondamentalement orthogonal à la largeur du pipeline.
Peter Cordes

Skylake est un bon cas d'optimisation par cycle d'horloge. les variantes ne sont pas nombreuses, ce qui n'est pas un cas intéressant d'optimisation de bus interne car les skylakes intègrent le déchargement d'origine Xeon dans le pipeline SIMD de cette façon. Je suppose qu'un grand cœur intégrerait le déchargement et le calcul en quelques cycles comme le fait (par exemple) les phénomènes pour AVX. c'est la façon dont le calcul s'est intégré en avant par rapport à la puissance requise pour les opérations de bloc interne. comme opposé à plusieurs instructions courtes comme dans Gpu-like avec plusieurs cœurs "virtuels" similaires aux ajouts au Nehalem
machtur
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.