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 pour les charges de travail à thread unique, mais potentiellement meilleure pour les charges de travail multi-thread?
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.
Réponses:
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 performances et de puissance différents. Par exemple, certains cœurs fonctionnent rapidement mais consomment beaucoup de puissance (architecture plus rapide et / ou des horloges plus élevées), tandis que d’autres sont écoénergétiques mais lents ( architecture plus lente et / ou horloges inférieures). 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 pour ordinateurs de bureau et ordinateurs portables actuels ne sont pas limités, du point de vue thermique ou électrique, au point où certains cœurs doivent fonctionner plus rapidement que d'autres, même pour de brèves rafales. Nous avons en gros mis le cap sur la rapidité avec laquelle nous pouvons créer des noyaux individuels . Par conséquent, 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 de Kaby Lake (cœur de 7e génération) et huit cœurs de Goldmont (Atom) lents . 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 Kaby Lake quadricœur normal . Cependant, les différents types de cœurs ont des niveaux de performances 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 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 risque donc de générer des performances inférieures à l'idéal, voire de planter 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 comme OpenCL et CUDA . En ce qui concerne une solution à puce unique, AMD favorise la prise en charge matérielle de l'accélération GPU de ses APU, qui associent un processeur traditionnel et un processeur graphique intégré hautes performances sur la même puce, tout comme l' architecture de système hétérogène , même si cela n'a pas été très bien accueilli par l'industrie. de quelques applications spécialisées.
la source
Ce que vous demandez, c'est pourquoi les systèmes actuels utilisent le multitraitement symétrique plutôt que le multitraitement asymétrique .
Le multitraitement asymétrique était utilisé autrefois, quand 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 à la 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é / éteint (lien: Sandy Bridge Architecture Exposed d'Intel ). (É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’a pas été fait - la question est "pourquoi pas". Comme indiqué ci-dessus, cela serait techniquement compliqué, donc plus coûteux et pour un gain financier insuffisant, voire inexistant, de sorte que les fabricants ne sont pas intéressés.
Voici les réponses à certains commentaires ci-dessous:
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 l'ensemble du processeur et de tous ses cœurs.
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).
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 de parcs bien 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 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 supplémentaire 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 de noyau individuelles.
la source
Il est possible que le téléphone dans votre poche affiche exactement cet arrangement - le bras 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 dans le désordre et d’optimisations du processeur).
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.
Le choix d’Intel ici est plutôt 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 source
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.
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.
Comparer différentes architectures est dangereux, mais bon ...
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 vite 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:
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 produite).
Et puis, il y a la production et le marketing et ça le gâche encore plus.
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, sur le PC de bureau typique, cela n’est pas fait. Cela rendrait l'installation beaucoup plus complexe, plus coûteuse et il n'y aurait pas de batterie à décharger.
la source
À 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?
la source
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'horloge de haut en bas. 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 commercial d'Intel) caractérisent chaque cœur en usine, les noyaux les plus rapides pouvant augmenter encore plus: http://www.anandtech.com/show/11550/the-intel -skylakex-review-core-i9-7900x-i7-7820x-et-i7-7800x-testé / 7
Les puces Bulldozer d’AMD avaient une version primitive: http://www.anandtech.com/show/4955/the-bulldozer-review-amd-fx8150-tested/4
Les nouvelles puces Ryzen d’AMD ont probablement cela aussi, bien que cela 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-et-1700/11
la source
Sur un système moderne vous souvent faire avoir tous les noyaux en cours d' exécution à des vitesses différentes. Le fait d’alimenter un cœur qui n’est pas trop 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 sont inactifs, et donc la consommation électrique. et la production de chaleur de l'ensemble du paquet ne va pas trop élevé. 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é ailleurs, il existe des puces couramment utilisées qui ne suivent pas ce principe de 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 liée à la vitesse d'horloge l’utilisation de l’énergie, tandis que les "petits" noyaux se rapprochent des racines d’ARM à problème unique, en ordre, de faible puissance), car ils
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.
la source
Des performances mono-thread rapides et un débit multi-thread très élevé sont exactement ce que vous obtenez avec un processeur tel que le processeur 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 débit maxi mono-cœur 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 unique et la bande passante L3 avec cache inférieur dans un grand Xeon signifient que son exécution ne sera peut-être pas aussi rapide qu'un quad-core de bureau à 3,6 GHz. Un seul cœur dans un processeur Intel de bureau peut utiliser beaucoup plus de 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 que 8 cœurs et qu’ils ont des budgets de puissance très élevés. Même les ordinateurs de bureau les plus enthousiastes montrent clairement cet effet: le Skylake-X i9-7900X d’Intel est une pièce 10c20t avec une base de 3,3 GHz, 4,5 GHz max . C'est bien plus que la marge de sécurité d'un seul noyau turbo par rapport à l'i7-6700k (turbo à 4 GHz / 4,2 GHz sans overclocking).
L'échelle de fréquence / tension (DVFS) permet au même noyau de fonctionner sur une large plage de la courbe performance / efficacité. Voir également 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 de manière statique à 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 exécuteront 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 style big.LITTLE pour en tirer le meilleur parti. Les petits noyaux dans ARM big.LITTLE sont des noyaux dans l’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 trouvé des discussions sur la raison pour laquelle x86 n'a pas big.LITTLE . Fondamentalement, dépenser plus de silicium sur un cœur très lent à très basse consommation n'en vaudrait pas la peine pour une utilisation typique d'un ordinateur de bureau / ordinateur portable.)
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
(
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. Certaines tâches parallèles embarrassantes évoluent presque linéairement (par exemple, compiler plusieurs fichiers source). Mais l' encodage vidéo n'est pas comme ça. Pour x264, la mise à l’échelle est très bonne jusqu’à quelques cœurs, mais elle s’aggrave avec plus de cœurs. Par exemple, passer de 1 à 2 cœurs doublera presque la vitesse, mais passer de 32 à 64 cœurs aidera beaucoup moins pour un codage 1080p typique. Le point auquel les plateaux de vitesse dépend des réglages. (
-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 programmer (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 la mémoire 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 sur autant de parties différentes du problème à la fois.
la source
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 "quizz buzzer" pourrait être mis en oeuvre avec aussi peu que deux transistors. Le problème est que prendre des décisions rapides qui sont fiablessans ambiguïté est difficile. Dans de nombreux cas, le seul moyen pratique de le faire consiste à utiliser un mécanisme appelé "synchroniseur", qui peut éviter 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 l'on était disposé à tolérer un délai de deux cycles pour chaque opération afin de déterminer le gagnant 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.
la source
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).
C'est un ordinateur avec quelques gros cœurs et beaucoup de petits cœurs.
En général, échanger un cœur sur X FLOPS contre trois à X / 2 FLOPS n’en vaut pas la peine; mais échanger un cœur à X FLOPS contre cent à 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 GPU obtienne les tâches optimales sur le GPU et que le CPU obtienne les tâches optimales sur le CPU.
Il est sans doute beaucoup plus facile d'écrire du code pour un processeur, car un code massivement parallèle est plus difficile à obtenir. Alors que lorsque le gain est important est qu'il vaut la négociation des performances monocœur pour les situations multi-core. 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.
la source
La raison pour laquelle les systèmes courants ont des cœurs à la même vitesse est un problème mathématique simple. Temporisation d'entrée et de sortie (avec optimisations) basée sur un seul ensemble de constantes (qui sont évolutives = multipliables par un nombre d'unités).
Et quelqu'un ici a dit que les appareils mobiles ont plusieurs processeurs à différentes vitesses. Ce n'est tout simplement pas vrai. Ce n'est pas une unité de traitement centrale si ce n'est pas l'unité de traitement central; peu importe ce que le fabricant dit qu'il est ou n'est pas. dans ce cas [pas un cpu] c'est juste un "paquet de support".
la source
Je ne pense pas que l'OP comprend l'électronique de base. Tous les ordinateurs ont besoin d’une chose pour fonctionner: une horloge. Les cycles d'horloge générés par une horloge interne sont le métronome pour le déplacement de toutes les données. Pour réaliser la synchronicité, toutes les opérations doivent être liées à une horloge commune. Cela vaut tant pour l'exécution de données internes sur un ordinateur isolé que pour des réseaux entiers.
Si vous souhaitez isoler les cœurs d'un processeur en les faisant fonctionner à différentes fréquences, vous pouvez certainement concevoir une telle plate-forme. Cependant, il faudrait concevoir une solution de carte mère associant chaque cœur à son propre sous-ensemble isolé de fonctionnalités de carte mère. Vous seriez laissé avec 4 ordinateurs individuels au lieu d'un ordinateur quad-core.
Comme le fait remarquer une autre personne, vous pouvez également ajouter à votre noyau un code permettant d’ajuster la fréquence de base sur une base individuelle. Cela provoquera des impacts sur les performances, cependant. Vous pouvez avoir une vitesse ou une efficacité énergétique - mais vous ne pouvez pas avoir les deux.
la source