Быстрая однопоточная производительность и очень высокая многопоточная пропускная способность - это именно то, что вы получаете с таким процессором, как Intel Xeon E5-2699v4 .
Это 22-ядерный Broadwell. Поддерживаемая тактовая частота составляет 2,2 ГГц со всеми активными ядрами (например, кодирование видео), но одноядерный макс турбо - 3,6 ГГц.
Поэтому, выполняя параллельную задачу, он использует свой бюджет мощности 145 Вт как 22 ядра по 6,6 Вт. Но при выполнении задачи с несколькими потоками тот же бюджет мощности позволяет нескольким ядрам работать на частоте до 3,6 ГГц. (Более низкая пропускная способность одноядерной памяти и L3-кэша в большом Xeon означает, что он может работать не так быстро, как настольный четырехъядерный процессор на частоте 3,6 ГГц. Одно ядро в настольном процессоре Intel может использовать гораздо больше общая пропускная способность памяти.)
Тактовая частота 2,2 ГГц является низкой из-за тепловых ограничений. Чем больше ядер у процессора, тем медленнее они должны работать, когда все они активны. Этот эффект не очень велик для 4- и 8-ядерных процессоров, о которых вы упоминаете в этом вопросе, потому что 8 не так много ядер, и у них очень высокий уровень энергопотребления. Даже настольные процессоры-энтузиасты заметно демонстрируют этот эффект: Intel Skylake-X i9-7900X представляет собой 10c20t-часть с базовой частотой 3,3 ГГц, максимальная турбо 4,5 ГГц . Это намного больше одноядерного турбо запаса мощности, чем у i7-6700k (4,0 ГГц устойчивый / 4,2 ГГц турбо без разгона).
Масштабирование частоты / напряжения (DVFS) позволяет одному и тому же ядру работать в широком диапазоне кривой производительности / эффективности. См. Также эту презентацию IDF2015 по управлению питанием Skylake , в которой много интересных деталей о том, что ЦП могут делать эффективно, и о соотношении производительности и эффективности как статически во время разработки, так и на лету с DVFS.
На другом конце спектра процессоры Intel Core-M имеют очень низкую постоянную частоту, например 1,2 ГГц при 4,5 Вт , но могут работать на частоте до 2,9 ГГц. С активными несколькими ядрами они будут работать с более эффективной тактовой частотой, как гигантские Xeon.
Вам не нужна гетерогенная архитектура стиля big.LITTLE, чтобы получить большую часть преимуществ. Маленькие ядра в ARM big.LITTLE - довольно дрянные ядра, которые не годятся для вычислительной работы. Дело в том, чтобы просто запустить пользовательский интерфейс с очень низким энергопотреблением. Многие из них не были бы хороши для кодирования видео или другого серьезного перебора чисел. ( @ Lưu Vĩnh Phúc нашел несколько рассуждений о том, почему у x86 нет big.LITTLE . По сути, тратить дополнительное количество кремния на сверхмалое сверхмалое ядро не стоило бы для обычного использования настольного компьютера или ноутбука.)
в то время как такие приложения, как редактирование видео, определяются количеством ядер. [Разве 2x 4,0 ГГц + 4x 2,0 ГГц не будут лучше при многопоточной рабочей нагрузке, чем 4x 4 ГГц?]
Это ваше ключевое недоразумение. Вы, кажется, думаете, что одинаковое количество тактов в секунду более полезно, если оно распределено по нескольким ядрам. Это никогда не так. Это больше похоже
cores * perf_per_core * (scaling efficiency)^cores
( perf_per_core
это не то же самое, что тактовая частота, потому что Pentium 4 с частотой 3 ГГц будет работать намного меньше за такт, чем Skylake с частотой 3 ГГц.)
Что еще более важно, очень редко, когда эффективность составляет 1,0. Некоторые смущающие параллельные задачи действительно масштабируются почти линейно (например, компиляция нескольких исходных файлов). Но кодирование видео не так. Для x264 масштабирование очень хорошо до нескольких ядер, но ухудшается с увеличением количества ядер. Например, от 1 до 2 ядер почти удвоит скорость, но от 32 до 64 ядер поможет гораздо меньше для типичного кодирования 1080p. Точка, в которой скорость плато зависит от настроек. ( -preset veryslow
больше анализирует каждый кадр и может занять больше ядер, чем -preset fast
).
С большим количеством очень медленных ядер однопоточные части x264 станут узкими местами. (Например, окончательное кодирование потока битов CABAC. Это эквивалент gzip для h.264 и не распараллеливание.) Наличие нескольких быстрых ядер решило бы это, если бы ОС знала, как это запланировать (или если x264 прикрепил соответствующие потоки к быстрые ядра).
x265 может использовать в своих интересах больше ядер, чем x264, поскольку у него больше анализа, а дизайн WP.2 в h.265 позволяет больше кодировать и декодировать параллелизм. Но даже для 1080p вам не хватает параллелизма для использования в какой-то момент.
Если у вас есть несколько видео для кодирования, хорошо работает несколько видео в параллельном масштабе, за исключением конкуренции за общие ресурсы, такие как емкость и пропускная способность кэша L3, а также пропускная способность памяти. Меньше более быстрых ядер могло бы получить больше преимуществ от того же объема кеша L3, так как им не нужно было бы работать сразу над многими разными частями проблемы.