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.

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.

2. 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.

3. 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.

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.

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.

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.

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.)

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.

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?".

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.

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

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

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.