«Пятничная угадайка», удивляющая своей иррациональностью и величиной цифр.
Если увеличить число процессорных ядер в 1,5 раза, не трогая ничего остального — как изменится время сборки проекта?
… оно тоже увеличится в 1,5 раза!
Не верите? И я не поверил. Предупреждаю сразу — ответа у меня всё ещё нет…
Дано:
Процессоры — OEM, их «официальные» аналоги 2680v3 и 2699v3. Единственное отличие — OEM умеют работать с DDR3. В остальном они близнецы-сёстры. Лок турбобуста отключен. Процессоры бустят все ядра, пока не упрутся в TDP (18 ядерник может единственное ядро аж до 3.8 добустить, но сейчас это не важно)
Сборка идёт в виртуалке. При этом не важно, на passthrough SSD SATA диске, или же cow2 образе, лежащем на SSD M2. Разница незаметна.
12 ядерники собирают примерно за час (real 66m, user 2705m, sys 126m)
18 ядерники собирают примерно за 1,5 часа (real 92m, user 5528m, sys 310m)
И это не поддаётся никакому обьяснению, ведь 18 ядерники ничем не хуже!
Может быть билд-система не умеет использовать столько ядер? Но тогда время было бы примерно равно 12 ядерникам, только часть ресурсов бы простаивала. На всякий случай проверим. Будем уменьшать число потоков, доступных билд системе:
Может один из 18 ядерных процессоров дефектный? Вынимаем по-очереди один, и второй. Получаем время сборки около 100m. Т.е. процессоры в порядке.
Изначально машина была одна. На которой и столкнулся с ситуацией, заменив только процессоры. Собрал вторую машину, на 18 ядерниках. Ситуация прекрасно воспроизвелась опять. У этой второй машины нет пользователей, и она более-менее свободна для тестов.
NUMA выглядит правдоподобным обьяснением. Но изменение топологии в QEMU/KVM на аналог хостовой не приносит никакого результата.
В сухом остатке:
1) добавление второго 12 ядерника ускоряет сборку почти линейно.
2) добавление второго 18 ядерника ускоряет сборку на ~10%.
Любые идеи и гипотезы приветствуются. Особенно которые легко проверить. Например, я бы с радостью проверил сборку няпрямую, без виртуалок, но свободного SSD хотя бы на 512Gb у меня просто нет. И систему с 2678 желательно не останавливать. (Т.е. вариант перетестировать с прямой загрузкой с HDD не подходит).
UPD: чтобы не вспоминали закон Амдалла приведу ещё такой пример. На 128/256 двухголовом EPYC (64 ядра каждый камень), 1Tb RAM, и NVMe RAID тот же AOSP собирается за 12 минут.
Если увеличить число процессорных ядер в 1,5 раза, не трогая ничего остального — как изменится время сборки проекта?
… оно тоже увеличится в 1,5 раза!
Не верите? И я не поверил. Предупреждаю сразу — ответа у меня всё ещё нет…
Дано:
- Платформа 2011-3, двухсокетная, чипсет C612.
- Хост ОС Ubuntu 20.04, виртуализация QEMU/KVM.
- Гостевая ОС Ubuntu 18.04 или 20.04. Не имеет значения.
- Памяти 256Gb, виртуальной машине выделено 96Gb.
- Собираемый проект AOSP.
- Процессоры (A) Xeon E5-2678v3: 12 ядер, 3300Mhz, 30mb cache, TDP 120w
- Процессоры (B) Xeon E5-2696v3: 18 ядер, 3600Mhz, 45mb cache, TDP 145w
Процессоры — OEM, их «официальные» аналоги 2680v3 и 2699v3. Единственное отличие — OEM умеют работать с DDR3. В остальном они близнецы-сёстры. Лок турбобуста отключен. Процессоры бустят все ядра, пока не упрутся в TDP (18 ядерник может единственное ядро аж до 3.8 добустить, но сейчас это не важно)
Сборка идёт в виртуалке. При этом не важно, на passthrough SSD SATA диске, или же cow2 образе, лежащем на SSD M2. Разница незаметна.
12 ядерники собирают примерно за час (real 66m, user 2705m, sys 126m)
18 ядерники собирают примерно за 1,5 часа (real 92m, user 5528m, sys 310m)
И это не поддаётся никакому обьяснению, ведь 18 ядерники ничем не хуже!
Может быть билд-система не умеет использовать столько ядер? Но тогда время было бы примерно равно 12 ядерникам, только часть ресурсов бы простаивала. На всякий случай проверим. Будем уменьшать число потоков, доступных билд системе:
- 72: 92m26s
- 48: 93m15s
- 36: 92m46s
- 18: 112m23s
Может один из 18 ядерных процессоров дефектный? Вынимаем по-очереди один, и второй. Получаем время сборки около 100m. Т.е. процессоры в порядке.
Изначально машина была одна. На которой и столкнулся с ситуацией, заменив только процессоры. Собрал вторую машину, на 18 ядерниках. Ситуация прекрасно воспроизвелась опять. У этой второй машины нет пользователей, и она более-менее свободна для тестов.
NUMA выглядит правдоподобным обьяснением. Но изменение топологии в QEMU/KVM на аналог хостовой не приносит никакого результата.
В сухом остатке:
1) добавление второго 12 ядерника ускоряет сборку почти линейно.
2) добавление второго 18 ядерника ускоряет сборку на ~10%.
Любые идеи и гипотезы приветствуются. Особенно которые легко проверить. Например, я бы с радостью проверил сборку няпрямую, без виртуалок, но свободного SSD хотя бы на 512Gb у меня просто нет. И систему с 2678 желательно не останавливать. (Т.е. вариант перетестировать с прямой загрузкой с HDD не подходит).
UPD: чтобы не вспоминали закон Амдалла приведу ещё такой пример. На 128/256 двухголовом EPYC (64 ядра каждый камень), 1Tb RAM, и NVMe RAID тот же AOSP собирается за 12 минут.
