Pourquoi avons-nous des processeurs dont tous les cœurs ont la même vitesse et non des combinaisons de vitesses différentes ?

Pourquoi n'avons-nous pas de variantes avec des vitesses d'horloge différentes ? Par exemple, deux "gros" cœurs et beaucoup de petits cœurs.

Les vitesses d'horloge nominales ne signifient pas grand-chose pour la plupart des gros processeurs de nos jours, car ils ont tous la capacité de s'auto-régler. Vous demandez s'ils peuvent ou non cadencer différents cœurs indépendamment.

Je suis un peu surpris par la plupart des autres réponses. Les processeurs modernes peuvent et font cela. Vous pouvez le tester, par exemple, en ouvrant CPU-Z sur un smartphone - mon Google Pixel est parfaitement capable de faire fonctionner différents cœurs à différentes vitesses :

Il est nominalement de 2,15 Ghz, mais deux cœurs sont à 1,593 Ghz et deux autres à 1,132 Ghz.

En fait, depuis 2009, les processeurs Intel grand public sont dotés d'une logique permettant d'augmenter le nombre de cœurs individuels tout en sous-clockant les autres cœurs, ce qui permet d'améliorer les performances d'un seul cœur tout en respectant le budget TDP : http://www.anandtech.com/show/2832/4

Les processeurs Intel plus récents dotés de la fonction "Favored Core" (un terme marketing d'Intel) ont chaque cœur caractérisé en usine, les cœurs les plus rapides pouvant être boostés à un niveau très élevé : http://www.anandtech.com/show/11550/the-intel-skylakex-review-core-i9-7900x-i7-7820x-and-i7-7800x-tested/7

Les puces Bulldozer d'AMD avaient une version primitive de ce système : http://www.anandtech.com/show/4955/the-bulldozer-review-amd-fx8150-tested/4

Les nouvelles puces Ryzen d'AMD probablement ont aussi cela, bien que ce ne soit pas explicitement indiqué ici : http://www.anandtech.com/show/11170/the-amd-zen-and-ryzen-7-review-a-deep-dive-on-1800x-1700x-and-1700/11

Sur un système moderne, vous avez souvent hacer avoir tous les noyaux fonctionnant à des vitesses différentes. Le ralentissement d'un cœur qui n'est pas très utilisé réduit la consommation d'énergie et la production thermique, ce qui est une bonne chose, et des fonctions comme 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 d'énergie et la production thermique de l'ensemble du système. paquet n'est pas trop élevée. Dans le cas d'une puce dotée d'une telle fonctionnalité, la vitesse que vous voyez dans la liste est 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 sont tous de conception identique, sur la même puce physique, élaborée avec le même processus de semi-conducteur, alors pourquoi seraient-ils différents ?

La raison pour laquelle tous les cœurs sont identiques est qu'il est plus facile pour un thread qui fonctionne sur un cœur à un moment donné de commencer à fonctionner sur un autre cœur à un autre moment. Comme mentionné ailleurs, il existe des puces couramment utilisées qui Ne le fais pas. suivent ce principe de cœurs identiques, à savoir les CPU ARM "big.LITTLE". Bien qu'à mon avis, la différence la plus importante entre les "grands" et les "petits" cœurs ne soit pas la vitesse d'horloge (les "grands" cœurs ont tendance à être des cœurs plus sophistiqués, plus larges, plus spéculatifs, qui obtiennent plus d'instructions par horloge au prix d'une plus grande consommation d'énergie, tandis que les "petits" cœurs se rapprochent davantage des racines de l'ARM en matière d'émission unique, d'ordre et de faible consommation), puisqu'il s'agit de conceptions différentes sur la même puce, ils 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 est également de plus en plus courant de voir des cœurs de "CPU" et de "GPU" intégrés sur la même puce. Ces derniers ont des conceptions complètement différentes, exécutent des jeux d'instructions différents, sont adressés différemment et sont généralement cadencés différemment également.

Des performances rapides pour un seul thread et un débit très élevé pour plusieurs threads, c'est exactement ce que vous obtenez avec un processeur tel que le Xeon E5-2699v4 d'Intel .

C'est un 22-core Broadwell. La vitesse d'horloge soutenue est de 2,2 GHz avec tous les cœurs actifs (par exemple l'encodage vidéo), mais la single-core max turbo est de 3.6GHz.

Ainsi, lors de l'exécution d'une tâche parallèle, il utilise son budget d'énergie de 145W pour 22 cœurs de 6,6W. Mais lors de l'exécution d'une tâche avec seulement quelques threads, ce même budget d'énergie permet à quelques cœurs de monter en puissance jusqu'à 3,6 GHz. la bande passante de la mémoire monocœur et du cache L3 dans un gros Xeon. Cela signifie qu'il ne fonctionnera peut-être pas aussi vite qu'un quadricœur de bureau à 3,6 GHz. Un seul cœur dans un processeur Intel de bureau peut utiliser beaucoup plus de la bande passante totale de la mémoire).

La vitesse d'horloge nominale de 2,2 GHz est aussi basse en raison des limites thermiques. Plus le nombre de cœurs d'un processeur est élevé, plus ils doivent fonctionner lentement lorsqu'ils sont tous actifs. Cet effet n'est pas très important dans les processeurs à 4 et 8 cœurs que vous mentionnez dans la question, car 8 cœurs ne sont pas si nombreux et leur budget énergétique est très élevé. Cet effet est perceptible même sur les processeurs des ordinateurs de bureau les plus performants : L'i9-7900X Skylake-X d'Intel est une pièce 10c20t avec une base de 3.3GHz, un turbo max de 4.5GHz. . C'est beaucoup plus que l'i7-6700k (4.0GHz soutenu / 4.2GHz turbo sans overclocking).

La mise à l'échelle de la fréquence et de la tension (DVFS) permet à un même cœur de fonctionner sur une large plage de la courbe performance/efficacité. Voir aussi cette présentation de l'IDF2015 sur la gestion de l'alimentation de Skylake Il y a beaucoup de détails intéressants sur ce que les processeurs peuvent faire efficacement, et sur le compromis entre performance et efficacité, à la fois de manière statique au moment de la conception et à la volée avec DVFS.

À l'autre extrémité du spectre, les processeurs Intel Core-M ont une fréquence soutenue très basse, comme 1.2GHz à 4.5W mais peuvent être turbo jusqu'à 2.9GHz. Avec plusieurs cœurs actifs, ils feront tourner leurs cœurs à une vitesse d'horloge plus efficace, tout comme les Xeons géants.

Vous n'avez pas besoin d'une architecture hétérogène de type big.LITTLE pour bénéficier de la plupart des avantages. Les petits cœurs de l'architecture ARM big.LITTLE sont des cœurs d'ordre plutôt médiocres qui ne conviennent pas au travail de calcul. Le but est simplement de faire fonctionner une interface utilisateur avec une puissance très faible. Un grand nombre d'entre eux ne serait pas idéal pour l'encodage vidéo ou d'autres calculs sérieux. ( @Luu Vinh Phúc a trouvé des discussions sur la raison pour laquelle x86 n'a pas de big.LITTLE. . En gros, dépenser du silicium supplémentaire pour un cœur très lent et à très faible puissance ne vaudrait pas la peine pour une utilisation typique d'un ordinateur de bureau/portable).

alors que des applications comme le montage vidéo sont déterminées par le nombre de cœurs. [Est-ce que 2x 4.0 GHz + 4x 2.0 GHz ne seraient pas meilleurs pour les charges de travail multithread que 4x 4GHz ?]

C'est là votre principal malentendu. Vous semblez penser que le même nombre total de ticks d'horloge par seconde est plus utile s'il est réparti sur plusieurs cœurs. Ce n'est jamais le cas. Il s'agit plutôt de

cores * perf_per_core * (scaling efficiency)^cores

( perf_per_core n'est pas la même chose que la vitesse d'horloge, car un Pentium4 à 3 GHz aura beaucoup moins de travail par cycle d'horloge qu'un Skylake à 3 GHz).

Plus important encore, il est très rare que l'efficacité soit de 1,0. Quelques terriblement parallèle Les tâches s'échelonnent de façon presque linéaire (par exemple, la compilation de plusieurs fichiers sources). Mais l'encodage vidéo est no comme ça. Pour x264, la mise à l'échelle est très bonne jusqu'à quelques cœurs, mais se dégrade avec l'augmentation du nombre de cœurs. Par exemple, passer de 1 à 2 cœurs doublera presque la vitesse, mais passer de 32 à 64 cœurs sera beaucoup moins utile pour un encodage 1080p typique. Le point auquel la vitesse plafonne dépend des paramètres. ( -preset veryslow fait plus d'analyse sur chaque trame, et peut occuper plus de cœurs que les -preset fast ).

Avec un grand nombre de cœurs très lents, les parties monofilaires de x264 deviendraient des goulots d'étranglement. (par exemple, l'encodage final du flux binaire CABAC. C'est l'équivalent de gzip pour h.264, et ne se parallélise pas). Le fait d'avoir quelques cœurs rapides résoudrait ce problème, si le système d'exploitation savait comment le planifier (ou si x264 affectait les threads appropriés aux cœurs rapides).

x265 peut tirer parti de plus de cœurs que x264, car il a plus d'analyses à effectuer, et la conception WPP de h.265 permet plus de parallélisme au niveau du codage et du décodage. Mais même pour le 1080p, il n'y a plus de parallélisme à exploiter à un moment donné.

Si vous avez plusieurs vidéos à encoder, faire plusieurs vidéos en parallèle est une bonne solution, à l'exception de la concurrence pour les ressources partagées comme la capacité et la bande passante du cache L3 et la bande passante de la mémoire. Des cœurs moins rapides pourraient tirer davantage de bénéfices de la même quantité de cache L3, puisqu'ils n'auraient pas besoin de travailler sur autant de parties différentes du problème à la fois.

Bien qu'il soit possible de concevoir des ordinateurs dont les différentes parties fonctionnent à des vitesses indépendantes différentes, l'arbitrage des ressources nécessite souvent de pouvoir décider rapidement quelle demande doit être traitée en premier, ce qui nécessite de savoir si une autre demande peut être arrivée suffisamment tôt pour être prioritaire. Décider de telles choses, la plupart du temps est assez simple. Quelque chose comme un circuit "quiz buzzer" pourrait être mis en œuvre avec seulement deux transistors. Le problème est que prendre des décisions rapides qui sont de manière fiable sans ambiguïté est difficile. La seule façon pratique de le faire dans de nombreux cas est d'utiliser une décision appelée "synchroniseur", qui peut éviter les ambiguïtés mais introduit un retard 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 séparées si l'on était prêt à tolérer un retard de deux cycles sur chaque opération pour déterminer qui a gagné l'arbitrage. Une telle approche serait cependant moins utile si l'on souhaite 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 retard de deux cycles.

Le fait de tout faire fonctionner à partir d'une horloge commune évite le besoin de synchronisation, ce qui évite un retard de communication de deux cycles chaque fois qu'il est nécessaire de faire passer des informations ou des signaux de contrôle entre les domaines d'horloge.

Les ordinateurs de bureau le font déjà.

Ils ont un (ensemble de) processeur(s), avec 1-72 threads actifs en même temps, et un (ensemble de) GPU(s), avec 16-7168 unités de calcul.

Le graphisme est un exemple de tâche pour laquelle nous avons constaté que le travail parallèle massif était efficace. Le GPU est optimisé pour effectuer le type d'opérations que nous voulons effectuer sur les graphiques (mais il n'est pas limité à cela).

C'est un ordinateur avec quelques gros cœurs, et lots de petits noyaux.

En général, échanger un cœur à X FLOPS contre trois cœurs à X/2 FLOPS n'en vaut pas la peine, mais échanger un cœur à X FLOPS contre cent cœurs à X/5 FLOPS en vaut vraiment la peine.

En programmant pour cela, vous générez un code très différent pour le CPU et pour le GPU. Un travail important est effectué pour diviser la charge de travail, afin que le GPU obtienne les tâches qui sont les mieux exécutées sur le GPU, et que le CPU obtienne les tâches qui sont les mieux exécutées sur le CPU.

Il est sans doute beaucoup plus facile d'écrire du code pour une unité centrale, car le code massivement parallèle est plus difficile à réaliser correctement. Donc seulement quand le gain est grand site Cela vaut-il la peine d'échanger les performances d'un seul cœur contre des situations multicœurs ? Les GPU sont très rentables lorsqu'ils sont utilisés correctement.

Maintenant, les appareils mobiles le font pour une raison différente. Ils disposent de cœurs à faible consommation qui sont nettement plus lents, mais consomment également beaucoup moins d'énergie par unité de calcul. Cela leur permet de prolonger l'autonomie de la batterie lorsqu'ils n'effectuent pas de tâches intensives pour le CPU. Il s'agit ici d'un autre type de "gain important" : pas de performances, mais d'efficacité énergétique. Il faut encore beaucoup de travail de la part du système d'exploitation et éventuellement du rédacteur de l'application pour que cela fonctionne correctement ; seul le gain important en vaut la peine.