Быстрая однопоточная производительность и очень высокая многопоточная пропускная способность - это именно то, что вы получаете с таким процессором, как 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.
Вам не нужно гетерогенное большое.МАЛЕНЬКАЯ архитектура стиля, чтобы получить большую часть выгоды. Маленькие ядра в ARM большие.LITTLE - довольно дурацкие ядра, которые не подходят для вычислительной работы. Дело в том, чтобы просто запустить пользовательский интерфейс с очень низким энергопотреблением. Многие из них не будут хороши для кодирования видео или другого серьезного перебора чисел. (@ Lưu Vĩnh Phúc нашел несколько дискуссий о том, почему x86 не имеет большого размера.МАЛЕНЬКИЙ. В принципе, тратить дополнительное количество кремния на очень медленное ядро с очень низким энергопотреблением не стоит для обычного использования настольного компьютера или ноутбука.)
в то время как такие приложения, как редактирование видео, определяются количеством ядер. [Разве 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. Это h.264 эквивалент gzip и не распараллеливается.) Наличие нескольких быстрых ядер решило бы это, если бы операционная система знала, как планировать это (или если x264 прикрепил соответствующие потоки к быстрым ядрам).
x265 может использовать в своих интересах больше ядер, чем x264, поскольку у него больше анализа, а дизайн WP.2 в h.265 позволяет больше кодировать и декодировать параллелизм. Но даже для 1080p вам не хватает параллелизма для использования в какой-то момент.
Если у вас есть несколько видео для кодирования, хорошо работает несколько видео в параллельном масштабе, за исключением конкуренции за общие ресурсы, такие как емкость и пропускная способность кэша L3 и пропускная способность памяти. Меньшее количество более быстрых ядер могло бы принести больше пользы от того же объема кеша L3, поскольку им не нужно было бы одновременно работать с таким большим количеством различных частей проблемы.