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