Pourquoi avons-nous des processeurs avec tous les cœurs à la même vitesse et non des combinaisons de vitesses différentes?
En général, si vous achetez un nouvel ordinateur, vous déterminez le processeur à acheter en fonction de votre charge de travail prévue. Les performances dans les jeux ont tendance à être déterminées par la vitesse d'un seul cœur, alors que les applications telles que le montage vidéo sont déterminées par le nombre de cœurs.
En termes de ce qui est disponible sur le marché - tous les processeurs semblent avoir à peu près la même vitesse, les différences principales étant plus de threads ou plus de cœurs.
Par exemple:
- Intel Core i5-7600K, fréquence de base de 3,80 GHz, 4 cœurs, 4 fils
- Intel Core i7-7700K, fréquence de base 4.20 GHz, 4 cœurs, 8 fils
- AMD Ryzen 5 1600X, fréquence de base 3.60 GHz, 6 cœurs, 12 fils
- AMD Ryzen 7 1800X, fréquence de base 3.60 GHz, 8 cœurs, 16 fils
Alors, pourquoi voyons-nous ce modèle d'augmentation des cœurs avec tous les cœurs ayant la même vitesse d'horloge?
Pourquoi n'avons-nous pas de variantes avec des vitesses d'horloge différentes? Par exemple, deux "gros" noyaux et beaucoup de petits noyaux.
Par exemple, au lieu de quatre cœurs à 4,0 GHz (4x4 GHz ~ 16 GHz maximum), qu’en est-il d’un processeur à deux cœurs à 4,0 GHz et de quatre cœurs à 2 GHz (2x4,0 GHz)? + 4x2.0 GHz ~ 16 GHz maximum). La deuxième option ne conviendrait-elle pas autant aux charges de travail à thread unique, mais potentiellement meilleure aux charges de travail à threads multiples?
Je pose cette question de manière générale - pas spécifiquement sur les processeurs que j'ai énumérés ci-dessus, ni sur une charge de travail spécifique en particulier. Je suis juste curieux de savoir pourquoi le motif est tel qu’il est.
Ceci est connu sous le nom de multitraitement hétérogène _ (HMP) et est largement adopté par les appareils mobiles. Dans les dispositifs basés sur ARM qui implémentent big.LITTLE , le processeur contient des cœurs avec des profils de performance et de puissance différents, par exemple. certains noyaux fonctionnent rapidement mais consomment beaucoup d'énergie (architecture plus rapide et/ou horloges supérieures), tandis que d'autres sont économes en énergie mais lents (architecture plus lente et/ou horloges plus basses). Ceci est utile car la consommation d'énergie a tendance à augmenter de manière disproportionnée lorsque vous augmentez les performances une fois que vous avez dépassé un certain point. L'idée ici est d'obtenir des performances lorsque vous en avez besoin et la vie de la batterie lorsque vous n'en avez pas.
Sur les plates-formes de bureau, la consommation d’énergie pose beaucoup moins de problèmes et n’est donc pas vraiment nécessaire. La plupart des applications s'attendent à ce que chaque cœur présente des caractéristiques de performance similaires, et les processus de planification des systèmes HMP sont beaucoup plus complexes que ceux des systèmes SMP traditionnels. (Windows 10 supporte techniquement HMP, mais il est principalement destiné aux appareils mobiles utilisant ARM big.LITTLE.)
De plus, la plupart des processeurs de bureau et de portables actuels sont non limités thermiquement ou électriquement au point où certains cœurs doivent fonctionner plus vite que d'autres, même pour de courtes rafales. Nous avons en gros mis le cap sur la rapidité avec laquelle nous pouvons créer des noyaux individuels , donc le remplacement de certains noyaux par des plus lents ne permettra pas aux noyaux restants de fonctionner plus rapidement.
Bien que quelques processeurs de bureau aient un ou deux cœurs capables de fonctionner plus rapidement que les autres, cette capacité est actuellement limitée à certains processeurs Intel très haut de gamme (comme la technologie Turbo Boost Max 3.0) et n'implique qu'un léger gain de performances. pour les noyaux qui peuvent courir plus vite.
Il est certes possible de concevoir un processeur x86 traditionnel avec des cœurs volumineux et rapides et des cœurs plus lents et plus lents à optimiser pour les charges de travail fortement threadées, mais cela compliquerait considérablement la conception du processeur et les applications ne le prendraient probablement pas en charge.
Prenons un processeur hypothétique avec deux cœurs rapides Kaby Lake (noyau de 7e génération) et huit cœurs lents Goldmont (Atom). Vous disposeriez d'un total de 10 cœurs et les charges de travail fortement threadées optimisées pour ce type de processeur pourraient enregistrer un gain de performances et d'efficacité par rapport à un processeur quadricœur Kaby Lake normal. Cependant, les différents types de cœurs ont des niveaux de performance très différents et les cœurs lents ne prennent même pas en charge certaines des instructions prises en charge par les cœurs rapides, comme AVX . (ARM évite ce problème en exigeant que les deux noyaux gros et LITTLE prennent en charge les mêmes instructions.)
Encore une fois, la plupart des applications multithread basées sur Windows partent du principe que chaque cœur a le même niveau de performances ou presque, et peut exécuter les mêmes instructions. Ce type d’asymétrie est donc susceptible d’entraîner des performances non optimales, voire des plantages si il utilise des instructions non prises en charge par les cœurs lents. Bien qu'Intel puisse modifier les cœurs lents pour ajouter une prise en charge des instructions avancées afin que tous les cœurs puissent exécuter toutes les instructions, cela ne résoudrait pas les problèmes de prise en charge logicielle pour les processeurs hétérogènes.
Une approche différente de la conception des applications, plus proche de ce à quoi vous pensez probablement dans votre question, utiliserait le processeur graphique pour accélérer les parties très parallèles des applications. Cela peut être fait en utilisant des API telles que OpenCL et CUDA . En ce qui concerne une solution à une seule puce, AMD favorise la prise en charge matérielle de l'accélération GPU de ses APU, qui associent un processeur traditionnel et un GPU intégré hautes performances sur la même puce, en tant que Architecture de système hétérogène , bien que cela ne se soit pas encore vu beaucoup d’industries en dehors de quelques applications spécialisées.
Ce que vous demandez, c'est pourquoi les systèmes actuels utilisent Multitraitement symétrique plutôt que Multitraitement asymétrique .
Le multitraitement asymétrique était utilisé jadis, lorsqu'un ordinateur était énorme et logé dans plusieurs unités.
Les processeurs modernes sont configurés comme une seule unité, dans une puce, où il est beaucoup plus simple de ne pas mélanger des processeurs de types différents, car ils partagent tous le même bus et la même RAM.
Il existe également la contrainte de l'horloge qui régit les cycles de la CPU et l'accès RAM. Cela deviendra impossible lors du mélange de processeurs à différentes vitesses. Les ordinateurs expérimentaux sans horloge existaient et étaient même assez rapides, mais la complexité du matériel moderne imposait une architecture plus simple.
Par exemple, les cœurs Sandy Bridge et Ivy Bridge ne peuvent pas fonctionner simultanément à des vitesses différentes car le bus de cache L3 fonctionne à la même vitesse d'horloge que les cœurs. Par conséquent, pour éviter les problèmes de synchronisation, ils doivent tous fonctionner à cette vitesse. ou être garé/désactivé (lien: Architecture Sandy Bridge d’Intel Exposed ). (Également vérifié dans les commentaires ci-dessous pour Skylake.)
[EDIT] Certaines personnes ont confondu ma réponse avec le sens qu'il était impossible de mixer des processeurs. Pour leur bénéfice, j’affirme: Le mélange de différents processeurs n’est pas au-delà de la technologie d’aujourd’hui, mais il n’est pas fait - la question est de savoir pourquoi. Comme indiqué ci-dessus, cela serait techniquement compliqué, donc plus coûteux et si le gain financier est insuffisant, voire nul, et n'intéresse donc pas les fabricants.
Voici les réponses à certains commentaires ci-dessous:
Turbo boost modifie la vitesse du processeur pour qu'ils puissent être modifiés
Le turbo boost se fait en accélérant le temps et en modifiant certains multiplicateurs, ce qui est exactement ce que font les gens quand on overclocke, sauf que le matériel le fait pour nous. L'horloge est partagée entre les cœurs d'un même processeur, ce qui accélère uniformément le processeur et tous ses cœurs.
Certains téléphones ont plus d'un processeur de vitesses différentes
Ces téléphones ont généralement une pile logicielle et logicielle personnalisée associée à chaque processeur, plus semblable à deux processeurs distincts (ou un processeur et un processeur graphique similaires), et ils ne disposent pas d’une vue unique de la mémoire système. Cette complexité est difficile à programmer et le multitraitement asymétrique a donc été laissé dans le domaine mobile, car il nécessite un développement logiciel de bas niveau proche du matériel, ce qui est évité par les systèmes d'exploitation de bureau universels. C’est la raison pour laquelle de telles configurations ne sont pas trouvées sur le PC (à l’exception de la CPU/du GPU si nous étirons suffisamment la définition).
Mon serveur avec 2x Xeon E5-2670 v3 (12 cœurs avec HT) a actuellement des cœurs à 1,3 GHz, 1,5 GHz, 1,6 GHz, 2,2 GHz, 2,5 GHz, 2,7 GHz, 2,8 GHz, 2,9 GHz et de nombreuses autres vitesses.
Un noyau est actif ou inactif. Tous les cœurs actifs en même temps fonctionnent à la même fréquence. Ce que vous voyez n'est qu'un artefact de synchronisation ou de calcul de la moyenne. J'ai moi-même également noté que Windows ne garait pas un noyau pendant une longue période, mais séparait plutôt tous les cœurs du parc beaucoup plus rapidement que le taux de rafraîchissement de Resource Monitor, mais je ne connais pas la raison de ce comportement qui est probablement en retard. la remarque ci-dessus.
Les processeurs Intel Haswell possèdent des régulateurs de tension intégrés qui permettent des tensions et des fréquences individuelles pour chaque cœur.
Les régulateurs de tension individuels diffèrent de la vitesse d'horloge. Tous les cœurs ne sont pas identiques - certains sont plus rapides. Les cœurs plus rapides reçoivent un peu moins de puissance, ce qui crée une marge de manœuvre pour augmenter la puissance donnée aux cœurs plus faibles. Les régulateurs de tension à cœur seront réglés aussi bas que possible afin de maintenir la vitesse d'horloge actuelle. L'unité de contrôle de l'alimentation de la CPU régule les tensions et remplace les requêtes du système d'exploitation, le cas échéant, pour les cœurs de qualité différente. Résumé: Les régulateurs individuels permettent de faire en sorte que tous les noyaux fonctionnent de manière économique à la même vitesse d'horloge, et non pour régler des vitesses individuelles.
Pourquoi n'avons-nous pas de variantes avec des vitesses d'horloge différentes? c'est à dire. 2 "gros" noyaux et beaucoup de petits noyaux.
Il est possible que le téléphone dans votre poche arbore exactement cet arrangement - le ARM big.LITTLE fonctionne exactement comme vous l'avez décrit. Dans ce cas, il n’ya même pas une simple différence de vitesse d’horloge, il peut s’agir de types de noyau totalement différents. En général, les plus lents sont encore plus "bêtes" (pas d’exécution inopérante ni d’optimisations de l’UC).
C'est une bonne idée essentiellement d'économiser la batterie, mais a ses propres inconvénients; la comptabilité pour déplacer des éléments entre différents processeurs est plus compliquée, la communication avec le reste des périphériques est plus compliquée et, plus important encore, pour utiliser efficacement ces cœurs, le planificateur de tâches doit être extrêmement intelligent (et souvent "deviner juste") .
La solution idéale consiste à exécuter des tâches d'arrière-plan non urgentes ou des tâches interactives relativement petites sur les "petits" noyaux et d'activer les "grandes" tâches uniquement pour les calculs volumineux et longs (où le temps supplémentaire passé sur les petits noyaux finit manger plus de batterie) ou pour des tâches interactives de taille moyenne, où l'utilisateur se sent léthargique sur les petits noyaux.
Cependant, le planificateur dispose d'informations limitées sur le type de travail que chaque tâche peut exécuter et doit recourir à une méthode heuristique (ou à des informations externes, telles que le masquage d'un masque d'affinité sur une tâche donnée) pour décider du calendrier de leur planification. Si cela se trompe, vous risquez de perdre beaucoup de temps et d’énergie à exécuter une tâche sur un cœur lent et à donner une mauvaise expérience utilisateur, ou à utiliser les "gros" noyaux pour des tâches de faible priorité, et donc à gaspiller de l’énergie/les voler loin des tâches qui en auraient besoin.
De plus, sur un système de multitraitement asymétrique, il est généralement plus coûteux de migrer des tâches vers un noyau différent de celui d'un système SMP. Le planificateur doit donc en principe deviner, au lieu d'essayer de s'exécuter sur un noyau libre aléatoire. il autour plus tard.
À la place, le choix d’Intel est d’avoir un nombre inférieur de cœurs intelligents et rapides identiques, mais avec une mise à l’échelle de fréquence très agressive. Lorsque le processeur est occupé, il atteint rapidement la vitesse d'horloge maximale, effectue le travail le plus rapidement possible, puis la réduit pour revenir au mode d'utilisation de la consommation la plus faible. Cela n'impose pas de charge particulière au planificateur et évite les mauvais scénarios décrits ci-dessus. Bien sûr, même en mode horloge basse, ces cœurs sont "intelligents", ils consommeront donc probablement plus que les cœurs "stupides" big.LITTLE.
La performance dans les jeux a tendance à être déterminée par la vitesse de base unique,
Dans le passé (jeux de l'ère DOS): Correct.
Ces jours-ci, ce n'est plus vrai. De nombreux jeux modernes sont filetés et bénéficient de plusieurs noyaux. Certains jeux sont déjà assez satisfaits avec 4 noyaux et ce nombre semble augmenter avec le temps.
tandis que les applications telles que l'édition vidéo sont déterminées par le nombre de cœurs.
Une sorte de vrai.
Nombre de cœurs * multiplié par la vitesse du cœur * efficacité.
Si vous comparez un seul noyau identique à un ensemble de noyaux identiques, vous avez généralement raison.
En termes de ce qui est disponible sur le marché - tous les processeurs semblent avoir à peu près la même vitesse, les différences principales étant plus de threads ou plus de cœurs. Par exemple:
Intel Core i5 7600k, fréquence de base 3,80 GHz, 4 cœurs Intel Core i7 7700k, fréquence de base 4,20 GHz, 4 cœurs, 8 fils AMD Ryzen 1600x, fréquence de base 3,60 GHz, 6 cœurs, 12 fils AMD Ryzen 1800x, base de 3,50 GHz, 8 noyaux, 16 fils
Comparer différentes architectures est dangereux, mais bon ...
Alors, pourquoi voyons-nous ce modèle d'augmentation des cœurs avec tous les cœurs ayant la même vitesse d'horloge?
En partie parce que nous avons rencontré une barrière. L'augmentation de la vitesse d'horloge signifie en outre plus de puissance et plus de chaleur. Plus de chaleur signifiait encore plus de puissance nécessaire. Nous avons essayé de cette façon, le résultat était l'horrible pentium 4. Chaud et affamé de pouvoir. Difficile de se calmer. Et pas même plus rapide que le Pentium-M au design intelligent (un P4 à 3,0 GHz était à peu près aussi rapide qu'un P-mob à 1,7 GHz).
Depuis lors, nous avons surtout abandonné la vitesse d'horloge pour créer des solutions plus intelligentes. Une partie de cela consistait à utiliser plusieurs cœurs sur la vitesse d'horloge brute.
Par exemple. Un seul cœur de 4 GHz peut consommer autant d’énergie et générer autant de chaleur que trois noyaux de 2 GHz. Si votre logiciel peut utiliser plusieurs cœurs, ce sera beaucoup plus rapide.
Tous les logiciels ne peuvent pas le faire, mais les logiciels modernes le peuvent généralement.
Ce qui répond en partie pourquoi nous avons des puces à plusieurs noyaux et pourquoi nous vendons des puces avec différents nombres de noyaux.
En ce qui concerne la vitesse d'horloge, je pense pouvoir identifier trois points:
- Les processeurs à faible consommation de puissance sont utiles dans de nombreux cas pour lesquels une vitesse brute n'est pas nécessaire. Par exemple. Contrôleurs de domaine, NAS configurations, ... Pour celles-ci, nous avons des processeurs à basse fréquence. Parfois, même avec plus de cœurs (par exemple, un processeur basse vitesse 8x est logique pour un serveur Web).
- Pour le reste, nous sommes généralement près de la fréquence maximale, ce que nous pouvons faire sans que notre conception actuelle ne devienne trop chaude. (disons de 3 à 4 GHz avec les conceptions actuelles).
- Et en plus de cela, nous faisons le binning. Tous les processeurs ne sont pas générés de manière égale. Certains processeurs obtiennent de mauvais résultats ou une mauvaise partie de leurs puces, désactivent ces pièces et sont vendus en tant que produit différent.
L'exemple classique en était une puce AMD à 4 cœurs. Si un cœur était brisé, il était désactivé et vendu en tant que puce à 3 cœurs. Lorsque la demande pour ces 3 cœurs était élevée, même quelques 4 cœurs étaient vendus comme version 3 cœurs, et avec le bon logiciel, vous pouviez réactiver le 4ème cœur.
Et cela ne se fait pas uniquement avec le nombre de cœurs, cela affecte également la vitesse. Certains copeaux sont plus chauds que d'autres. Trop chaud et vendez-le comme un processeur à faible vitesse (où une fréquence plus basse signifie également moins de chaleur générée).
Et puis, il y a la production et le marketing et ça le gâche encore plus.
Pourquoi n'avons-nous pas de variantes avec des vitesses d'horloge différentes? c'est à dire. 2 "gros" noyaux et beaucoup de petits noyaux.
Nous faisons. Dans les endroits où cela a du sens (par exemple, les téléphones mobiles), nous avons souvent un SoC avec un cœur de processeur lent (faible consommation) et quelques cœurs plus rapides. Cependant, dans le PC de bureau typique, cela n’est pas fait. Cela rendrait l'installation beaucoup plus complexe, plus onéreuse et il n'y aurait pas de batterie à épuiser.
Pourquoi n'avons-nous pas de variantes avec des vitesses d'horloge différentes? Par exemple, deux "gros" noyaux et beaucoup de petits noyaux.
À moins que nous soyons extrêmement préoccupés par la consommation d’énergie, il n’aurait aucun sens de prendre en charge tous les coûts associés à un cœur supplémentaire et de ne pas tirer le maximum de performances de ce cœur. La vitesse d'horloge maximale est déterminée en grande partie par le processus de fabrication, et la puce entière est fabriquée selon le même processus. Alors, quel serait l’avantage de rendre certains des noyaux plus lents que le processus de fabrication pris en charge?
Nous avons déjà des noyaux qui peuvent ralentir pour économiser de l'énergie. Quel serait l'intérêt de limiter leurs performances maximales?
Pourquoi n'avons-nous pas de variantes avec des vitesses d'horloge différentes? Par exemple, deux "gros" noyaux et beaucoup de petits noyaux.
Les vitesses d'horloge nominales ne signifient pas vraiment grand chose pour la plupart des plus gros processeurs de nos jours, car ils ont tous la capacité de s'auto-synchroniser. Vous leur demandez s'ils peuvent ou non synchroniser différents noyaux indépendamment.
Je suis un peu surpris par beaucoup d'autres réponses. Les processeurs modernes peuvent le faire et le font. Vous pouvez le tester, par exemple, en ouvrant la CPU-Z sur un smartphone - mon Google Pixel est parfaitement capable de faire fonctionner différents cœurs à différentes vitesses:
Il est nominalement à 2,15 Ghz, mais deux cœurs sont à 1,593 Ghz et deux à 1,132 Ghz.
En fait, depuis 2009, les principaux processeurs Intel ont eu la logique d'augmenter le nombre de cœurs individuels tout en sous-stockant les autres, ce qui permet d'améliorer les performances d'un cœur tout en respectant le budget TDP: http://www.anandtech.com/show/2832/4
Les processeurs Intel les plus récents avec "Favored Core" (terme marketing d'Intel) ont chaque noyau caractérisé en usine, les cœurs les plus rapides pouvant augmenter très haut: http://www.anandtech.com/show/11550/the -intel-skylakex-review-core-i9-7900x-i7-7820x-and-i7-7800x-testé/7
Les puces Bulldozer d’AMD en possédaient une version primitive: http://www.anandtech.com/show/4955/the-bulldozer-review-AMD-fx8150-tested/4
Les nouvelles puces Ryzen d’AMD probablement ont également cette caractéristique, bien que cela ne soit pas explicitement indiqué ici: http://www.anandtech.com/show/11170/the-AMD-zen-and-ryzen-7 -review-a-deep-plonge-on-1800x-1700x-and-1700/11
Sur un système moderne, vous avez souvent do tous les cœurs tournant à des vitesses différentes. Le fait d’alimenter un cœur peu utilisé réduit la consommation d’énergie et la puissance thermique, ce qui est bien, et des fonctionnalités telles que le "turbo boost" permettent à un ou deux cœurs de fonctionner beaucoup plus vite tant que les autres cœurs sont inactifs, et donc la consommation et le dégagement de chaleur de l'ensemble package ne va pas trop haut. Dans le cas d'une puce dotée d'une telle fonctionnalité, la vitesse indiquée dans la liste correspond à la vitesse la plus élevée que vous pouvez obtenir avec tous les cœurs en même temps. Et pourquoi tous les cœurs auraient-ils la même vitesse maximale? Eh bien, ils ont tous la même conception, sur la même puce physique, installés avec le même processus de semi-conducteur, alors pourquoi devraient-ils être différents?
La raison pour laquelle tous les cœurs sont identiques est qu’il est plus facile pour un thread qui s’exécute sur un cœur à un moment donné de commencer à s’exécuter sur un cœur différent à un autre moment. Comme mentionné précédemment, il existe des puces couramment utilisées qui ne suivent pas le principe des cœurs identiques, à savoir les processeurs ARM "big.LITTLE". Bien que, dans mon esprit, la différence la plus importante entre les "grands" et les "petits" noyaux ne soit pas la vitesse d'horloge (les "grands" noyaux ont tendance à être plus fantaisistes, des noyaux plus volumineux, plus spéculatifs qui obtiennent plus d'instructions par horloge au prix de consommation d’énergie, tandis que les "petits" noyaux se rapprochent des racines d’Arm à problème unique, dans l’ordre, de faible puissance), puisqu’il s’agit de conceptions différentes sur la même puce, elles auront généralement des vitesses d’horloge maximales différentes.
Et pour aller plus loin dans le domaine de l'informatique hétérogène, il devient également courant de voir les cœurs "CPU" et "GPU" intégrés sur la même puce. Celles-ci ont des conceptions radicalement différentes, exécutent différents jeux d'instructions, sont traitées différemment et sont généralement synchronisées différemment.
Les performances mono-thread rapides et le débit multi-thread très élevé sont exactement ce que vous obtenez avec un processeur tel que Intel Xeon E5-2699v4.
C'est un Broadwell à 22 cœurs. La vitesse d'horloge soutenue est de 2,2 GHz avec tous les cœurs actifs (par exemple, le codage vidéo), mais le turbo max à cœur unique est de 3,6 GHz.
Ainsi, tout en exécutant une tâche parallèle, il utilise son budget de puissance de 145W sous forme de 22 cœurs de 6.6W. Mais même si vous exécutez une tâche avec seulement quelques threads, le même budget énergétique permet à quelques cœurs de fonctionner jusqu'à 3,6 GHz. (La mémoire mémoire inférieure à un cœur et bande passante L3 inférieure dans un grand Xeon signifie qu’elle ne fonctionnera peut-être pas aussi vite qu’un quad-core de bureau à 3,6 GHz). Un seul cœur dans un processeur Intel de bureau peut utiliser une beaucoup plus de la bande passante mémoire totale.)
La vitesse d'horloge nominale de 2,2 GHz est si basse en raison des limites thermiques. Plus le nombre de cœurs d'un processeur est élevé, plus son exécution est lente lorsqu'ils sont tous actifs. Cet effet n’est pas très important dans les processeurs à 4 et 8 cœurs que vous avez mentionnés dans la question, car ils n’ont pas beaucoup de cœurs et ils ont des budgets de puissance très élevés. Même les processeurs de bureau enthousiastes montrent clairement cet effet: le Skylake-X i9-7900X d’Intel est une pièce 10c20t avec une base de 3,3 GHz, un turbo maxi à 4,5 GHz . C’est beaucoup plus simple que le i7 -6700k (4,0 GHz soutenu/4,2 GHz turbo sans overclocking).
La mise à l'échelle fréquence/tension (DVFS) permet au même noyau de fonctionner sur une large plage de la courbe performance/efficacité. Voir aussi cette présentation IDF2015 sur la gestion de l'alimentation de Skylake , avec de nombreux détails intéressants sur ce que les processeurs peuvent faire de manière efficace, et sur le compromis performances/efficacité à la fois statiquement au moment de la conception et à la volée avec DVFS.
À l’autre bout du spectre, les processeurs Intel Core-M ont une fréquence soutenue très basse, comme 1,2 GHz à 4,5 W , mais peuvent atteindre jusqu’à 2,9 GHz. Avec plusieurs cœurs actifs, ils fonctionneront à une vitesse d'horloge plus efficace, tout comme le Xeons géant.
Vous n'avez pas besoin d'une architecture hétérogène de style big.LITTLE pour en tirer le meilleur parti. Les petits cœurs dans ARM big.LITTLE sont des cœurs en ordre plutôt merdiques qui ne conviennent pas au calcul. Il s’agit simplement de gérer une interface utilisateur à très basse consommation. Beaucoup d'entre eux ne seraient pas parfaits pour l'encodage vidéo ou d'autres calculs sérieux. ( @ (@ Lưu Vĩnh Phúc) a discuté de la raison pour laquelle x86 n'a pas big.LITTLE . Fondamentalement, dépenser plus de silicium sur un noyau très lent à très basse consommation n'en vaudrait pas la peine pour un ordinateur de bureau/portable typique usage.)
tandis que les applications telles que l'édition vidéo sont déterminées par le nombre de cœurs. [2x 2x 4.0 GHz + 4x 2.0 GHz ne serait-il pas meilleur pour des charges de travail multithreads que 4x 4x GHz?]
Ceci est votre malentendu clé. Vous semblez penser que le même nombre total de ticks d'horloge par seconde est plus utile s'il est réparti sur plus de cœurs. Ce n'est jamais le cas. C'est plus comme
cores * perf_per_core * (scaling efficiency)^cores
(perf_per_core n'est pas la même chose que la vitesse d'horloge, car un Pentium 4 3GHz aura beaucoup moins de travail par cycle d'horloge qu'un Skylake 3GHz.)
Plus important encore, il est très rare que l'efficacité soit de 1,0. Certains parallèlement embarrassant tâches font l’échelle presque linéairement (par exemple, compiler plusieurs fichiers source). Mais le codage vidéo est pas comme ça. Pour x264, la mise à l’échelle est très bonne jusqu’à Par exemple, passer de 1 à 2 noyaux doublera presque la vitesse, mais passer de 32 à 64 noyaux aidera beaucoup moins pour un encodage 1080p typique. Le point auquel les plateaux de vitesse dépendent du (-preset veryslow effectue plus d’analyses sur chaque image et peut occuper plus de cœurs que -preset fast).
Avec beaucoup de cœurs très lents, les parties à un seul fil de x264 deviendraient des goulots d'étranglement. (Par exemple, le codage final du flux binaire CABAC. C’est l’équivalent de gzip en h.264 et il ne parallélise pas.) Avoir quelques cœurs rapides résoudrait ce problème, si le système d’exploitation savait le planifier (ou si x264 épinglait les threads appropriés à noyaux rapides).
x265 peut exploiter plus de cœurs que x264, car il a plus d'analyse à faire et la conception WPP de h.265 permet davantage de codage et de décodage du parallélisme. Mais même pour 1080p, vous n’avez plus de parallélisme à exploiter.
Si vous avez plusieurs vidéos à encoder, vous pouvez en faire plusieurs parallèles, à l'exception de la concurrence pour les ressources partagées telles que la capacité de cache N3, la bande passante et la bande passante mémoire. Moins de cœurs plus rapides pourraient tirer davantage parti de la même quantité de cache L3, car ils n'auraient pas besoin de travailler simultanément sur autant de parties différentes du problème.
Bien qu'il soit possible de concevoir des ordinateurs dont différentes pièces fonctionnent à différentes vitesses indépendantes, l'arbitrage de ressources nécessite souvent de pouvoir décider rapidement quelle requête doit être traitée en premier, ce qui nécessite de savoir si une autre requête aurait pu arriver assez tôt pour être prioritaire. . Décider de telles choses, la plupart du temps , est assez simple. Un circuit de type "quiz buzzer" pourrait être mis en oeuvre avec aussi peu que deux transistors. Le problème est que prendre des décisions rapides qui sont de manière fiable sans ambiguïté est difficile. Dans de nombreux cas, le seul moyen pratique de le faire consiste à utiliser un mécanisme appelé "synchroniseur", qui évite les ambiguïtés mais introduit un délai de deux cycles. On pourrait concevoir un contrôleur de mise en cache qui arbitrerait de manière fiable entre deux systèmes avec des horloges distinctes si on était disposé à tolérer un délai de deux cycles pour chaque opération afin de déterminer le vainqueur de l'arbitrage. Une telle approche serait toutefois peu utile si l'on souhaitait qu'un cache réponde immédiatement aux demandes en l'absence de conflit, car même les demandes non contestées auraient toujours un délai de deux cycles.
Tout exécuter sur une horloge commune évite le besoin de synchronisation, ce qui évite un délai de communication de deux cycles chaque fois qu'il est nécessaire de transmettre des informations ou des signaux de contrôle entre des domaines d'horloge.
Les ordinateurs de bureau le font déjà.
Ils ont (ensemble de) un processeur (s), avec 1-72 threads actifs en même temps, et un (ensemble de) GPU (s), avec 16-7168 unités de calcul.
Les graphiques sont un exemple de tâche pour laquelle nous avons constaté que le travail en parallèle était efficace. Le GPU est optimisé pour effectuer le type d'opérations pour lequel nous souhaitons créer des graphiques (mais ce n'est pas limité à cela).
Ceci est un ordinateur avec quelques gros cœurs et lots de petits cœurs.
En général, échanger un cœur sur X FLOPS contre trois cœurs sur X/2 FLOPS n'en vaut pas la peine; mais échanger un noyau à X FLOPS contre cent noyaux à X/5 FLOPS en vaut vraiment la peine.
Lors de la programmation, vous générez un code très différent pour la CPU et pour le GPU. Beaucoup de travail est fait pour diviser la charge de travail, de sorte que le processeur graphique obtienne les tâches optimales sur le processeur graphique et que le processeur obtienne les tâches optimales sur le processeur.
Il est sans doute beaucoup plus facile d'écrire du code pour un processeur, car un code massivement parallèle est plus difficile à obtenir. Donc, lorsque le gain est grand , cela vaut-il la peine d’échanger des performances monocœurs pour des situations multicœurs? Les GPU sont très rentables s’ils sont utilisés correctement.
Maintenant, les appareils mobiles le font pour une raison différente. Ils ont des noyaux à faible consommation qui sont nettement plus lents, mais qui consomment également beaucoup moins d'énergie par unité de calcul. Cela leur permet de prolonger la durée de vie de leur batterie beaucoup plus longtemps sans effectuer de tâches gourmandes en ressources CPU. Nous avons ici un type différent de "gros gain"; pas la performance, mais l'efficacité énergétique. Il faut encore beaucoup de travail de la part du système d’exploitation et peut-être du rédacteur de l’application pour que cela fonctionne correctement; seul le gros gain en a valu la peine.