Comments 54
У вас чудо чудное только при сборке AOSP? Как я понял из поста, вы ничего другого не тестили. Попробуйте замерять время сборки, скажем linux kernel на 12ядрах и на 18ти.
Гипотезы:
Ошибки в условиях тестирования или сбора результатов.
Пределы масштабирования используемого ПО (издержки на согласование результатов работы всех ядер становятся выше полезного вклада отдельного ядра). Возможно, плохая масштабируемость многопоточности (для данного профиля нагрузки) затаилась прям в операционной системе или в ограничениях системы виртуализации.
Троттлинг из-за перегрева более многоядерного процессора или его более жёсткое воздержание от турбобустов при загрузке всех ядер (во избежание перегрева).
Злоумышленник, подделывающий результаты или намеренно замедляющий вашу гостевую систему на слишком жирных процессорах (может, продаёт ваши ядра на сторону или майнит на них что-нибудь).
Случайное совпадение, радиоактивный фон, влияющий на вычисления, проклятие или наведённая порча.
Исключено. Но можем провести другие тесты.
масштабирование-согласование не обьясняет, почему 48 потоков на 18 ядрах работают намного хуже 48 потоков на 12 ядрах
Серверный корпус, хороший обдув, холод в помещении. Температуры отличные.
Хост система чистая, установленна с нуля сутки назад. Тестовую виртуалку могу выложить для ознакомления.
Слишком хорошее воспроизведение ((
Второй и третий пункт вы не опровергли.
Второй большой очень. Про виртуализации мне нечего ответить.
Третий опроверг. И за температурами наблюдал. Они в норме.
Температура могла быть в норме именно из-за управления частотами ядер (сдерживания их турбобуста). Ну и устойчивость проклятия вы недооценили :).
Турбобуст как раз не сдерживается. Он разлочен в UEFI сторонний утилитой. 12 ядерники бустятся до стабильных 3300 по всем ядрам, 18 ядерники до 3200-3600. Упор мог быть только в TDP. Но он выше у 18 ядерников, поэтому не объясняет их отставание
Ну вы сами столько различий описали, а потом вдруг анулировали их совершенно беспредметным тезисом. Вот и померяйте, на каких частотах в итоге отработали ваши ядра, увеличение теплопакета не гарантирует более эффективного расхода этого пакета (при масштабировании физических устройств издержки синхронизации ядер выражаются в том числе и в лишнем тепле).
Так нарисуйте график частоты ядер от времени. Думаю, вас ждёт сюрприз.
Кроме того, процессор может тротлится и не снижая частоту, просто пропуская такты. Это тоже где-то можно обнаружить (в смысле, прочитать в /proc или /sys), но не помню где.
а почему именно 48 потоков и там и там ? логичнее сделать на Xeon E5-2678v3 24 потоков а на Xeon E5-2696v3 - 36 потоков. иначе у вас получается что лишние потоки отнимают время на переключения
А мне кажется как раз неплохо объясняет... 48/18 = 2.6, как они там по ядрам в таком случае распределяются - вопрос к специалистам, а при 48/12 всё ровненько и раз процессы одинаковые, почему б им не занимать место в памяти оптимальнее?
Загрузка всех потоков 100% основную часть времени. Хоть на 12, хоть на 18 ядерниках. Простоя ядер не видно.
36/18 тоже ровненько. И 72/18. А результат странный.
Более того, 48/18 = 2,6666666666(6).... Мне кажется, что совокупность програмно-аппаратных средств при такой конфигурации представима в виде вычислителя который пытается разделить 2 на 3, с бесконечной точностью, что в принципе недостижимо. Видимо в процессе где-то есть переход который при переключении потока выполняет "код деления" и записывает виртуальные 6-ки в виртуальный результат :). Кстати угадайка вполне себе рациональна. Каким способом не делить 3 на 2, в итоге получишь полтора! Попробуйте поиграйтесь с кратностью потоков.
48 на 12 делится нацело, а на 18 нет, это может влиять.
2.1 - предел масштабирования может быть и в IO, это и предельные ограничения многопоточного доступа к физическому устройству / файловой системе, и ограничения настроек на количество одновременно открываемых файлов.
Похоже вы открыли тайну... добавление мощностей не приводит к линейному масштабированию. Это базовое правило, которое по-моему уже все давно учитывают при построении больших систем.
Обусловливается как пределами масштабирования, так и накладными расходами на параллелизацию.
Например, я бы с радостью проверил сборку няпрямую, без виртуалок
Было бы неплохо все же проверить на bare metal, дабы исключить влияние виртуализации.
Я наблюдал такую ситуацию, что при распределении CPU/RAM-intensive нагрузки на большое количество ядер (один 64-ядерник EPYC) производительность на ядро падала вплоть до 2-х раз, но только в QEMU. На bare metal та же нагрузка масштабировалась нормально.
Попробуйте уменьшить число ядер для сборки. Например в 1.5 раза :)
И это не поддаётся никакому обьяснению, ведь 18 ядерники ничем не хуже!
у 12-ядерника базовая частота выше. 2.3 Ghz vs 2.5 Ghz
Tcase у 12-ядерника выше 84.5 vs 76.4. Не до конца понимаю этот параметр, но допускаю что 12 может дольше работать в режиме Turbo Boost.
https://ark.intel.com/content/www/ru/ru/ark/compare.html?productIds=81908,81061
Т.е. причина может быть в том что 12 ядерник дольше работает в turbo boost, но даже когда буст выключается и проц работает на базовой частоте, он все равно быстрее в расчете на ядро.
---
upd
В общем и целом, нужны графики нагрузки на каждое ядро, суммарная нагрузка на процессор, графики температуры и частоты ядер.
Выглядит как лимит на глубину очереди блочного устройства. Возможно, спинлоки где-то в коде блочных устройств приводят к прпорциональному замедлению.
Попробуйте собрать LVM в режиме interleave из нескольких виртуальных устройств. raid0 тоже можно, но у него есть некоторые проблемы своего рода в районе высокой производительности.
По спецификации у процессоров, кажется, есть отличие: поддержка Transactional Synchronization Extensions 12-ти ядерным процессором, которой на первый взгляд нет у 18-ти ядерного. Для сборки это потенциально как раз порядка 30% за счёт ускорения межпоточной синхронизации
Можно попробовать отключить флагами компилятора (пересобрать сам компилятор без поддержки TSE), или лучше аппаратно флагами ядра и проверить
upd: https://www.cpu-world.com/Compare_CPUs/Intel_CM8064401610101,Intel_CM8064401967500/
Может ли быть ограничение в чтение данных с диска. Есть такой прикол, что файл в 1 ГБ копируется за минуту, а если 2 файла паралельно копировать то это займет 10 минут
>QEMU
Ключевое слово здесь. Во-первых, является ли эта задача CPU-bound или IO-bound? Более вероятно второе - смотрите количество потоков, порождаемых этой поделкой, и потребление памяти. Если потоков слишком много, то это оно (там IO так сделан), и надо подбирать бэкэнд среди нескольких полурабочих
1) скачать интеловскую утилиту мониторинга, посмотреть, что конкретно в процессоре загружено https://github.com/opcm/pcm .
2) Посмотреть статистику локов в ядре (возможно, придется пересобирать ядро)
3) Попробовать пересобрать с build_tree на tmpfs
4) попробовать запустить в параллель две сборки на одной и разной файловых системах.
5) сравнить kernel time/ user time.
Гипотеза 1): где-то, например в драйвере файловой системы или устройства, есть мьютекс, в спин-локе которого и просирается время.
Гипотеза 2): избыток ядер порождает избыток какого-то служебного трафика по процессорным шинам, например сообщений протокола когерентности кэша, который засирает какую-то критическую шину, например относительно узкий межпроцессорный линк QPI
Поставить тот же опыт, использовав Hyper-V Core. Было бы интересно...
во-первых, зачем собирать под виртуалкой, пусть даже с kvm? скорей всего в ней и проблема. если какая-то несовместимость с системными либами - можно ведь докер взять.
во-вторых, аосп аоспу рознь, но
12 ядерники собирают примерно за час (real 66m, user 2705m, sys 126m)
18 ядерники собирают примерно за 1,5 часа (real 92m, user 5528m, sys 310m)
мой домашне-рабочий пк на 5950x, 64gb ram собирает наш аосп за 25 минут. процентов 10-15 этого времени - генерация жирных образов прошивок (которые не часть аоспа).
А попробуйте отключить SMT в BIOS ради эксперимента, если ещё нет.
Я в компьютерах совсем не понимаю, но интуиция подсказывает - собака зарыта в кратности. Поскольку (постольку) я в компьютерах ничего не понимаю, то и пояснять не возьмусь. Но истина - где-то рядом (смотри комментарии, где упоминается кратность чисел и копай в сторону оптимизации (экономии вычислений), высосанной кожаным мешком из собственного пальца: 2*2 вседа равно 4, так и кладём большой прибор на 2*2, и просто пишем 4. Это не точно, это интуиция...
Я бы проверил для начала производительность процессоров в бенчмарках на других задачах. Может быть это вообще китайская подделка )). Я каноны брал с АлиЭкспресс только последнее время
Тайна числа 1,5