Xeon E5-2ххх, производительность при отключении ядер?
Приветствую!
Прошу помочь понять и осмыслить экспериментальные данные.
Задача:
Понять каков оптимальный конфиг железа при сшивке т.н. гигапиксельных панорам (для меня это важно).
Коллега любезно предоставил для теста такую машинку:
Supermicro X9DRi-F + 2 шт E5-2660 + 128gb
Мы гоняли разные тесты на основании сырья снятой мною в прошлом году панорамы. 684 кадра по 18 или 36мп.
Термины:
Warp — именно работа с геометрией, именно сшивка кадров;
Blending — выравнивание цвета и яркости по всему полю из всех жипегов.
Результаты такие:
0. 18мп исходники пережевываются ровно в 2 раза быстрее, чем 36мп исходники;
1. Включение НТ — дает проседание скорости варпа на 15-20% (для любого количества ядер);
2. И для 18мп и для 36мп исходных кадров скорость варпа на 12 (2х6) или 16 (2х8) ядрах — совершенно одинаковая, +2 ядра на процессор не дают никакого прироста, -2 ядра на процессор не дают никакого проседания;
3. Дальнейшее уменьшение числа активных ядер уже приводит к падению скорости варпа;
4. Загрузка процессора (по условным процентам диспетчера задач) никогда (!) не доходит до 100%, пики на 90%;
5. Оперативная память на стадии варпа полностью не выедается: для 18мп исходников — в пике занято 35-40гб из 128, для 36мп исходников в пике занято 75-90гб из 128;
6. Обращения к накопителю не особо впечатляют. Довольно быстро записывается кэш в 26 или 53гб (для 18 и 36мп сырья, соответственно). Это соразмерно будущему результирующему файлу. Затем, в течение получаса или часа записывается примерно 15гб кэшей, и считывается примерно 10гб. Т.е. упираться в производительность дисковой подсистемы негде. К тому же там чередующийся рейд из 4 дисков;
7. Ну а на стадии блендинга оперативная память выедается моментально и вся сразу. И сотни гигабайт кэшей пишутся\читаются. А загрузка процессора не выше 4-8%.
Вопросы:
1. Логично ли мое предположение о том, что все упирается в кэши процессоров? Или дело может быть в чем-то другом?
2. При отключении двух ядер весь процессорный кэш распределяется между оставшимися шестью? Или часть кэша тоже простаивает?
3. Что логичнее: и дальше собирать систему на 8-ядерниках, но работать только на 6 ядрах или сразу брать 6-ядерные процессоры? Но тут нюанс, L2 кэш «на ядро» у 6 и 8 ядерных процессоров одинаковый.
IMHO, без указания ОС, а тем более используемого ПО что-либо советовать бесполезно.
Применяемая для данных задач autopano giga есть под все 3 платформы, и попробовать trial дают.
Ваши ресурсы в несколько раз больше тех, на которых создавались панорамы на 20 гигапикселей.
Для примера, 26 гигапиксельная панорама Парижа рендерилась на 2 Intel Xeon processors 5500 24 GB RAM, 1 TB SSD около 3 часов. Т.е. Ваш пример (8-16 гигапикселей на вдвое большем числе ядер) будет примерно за час, и подобрать параметры ПО и числа ядер можно за несколько прогонов в течении дня. blog.paris-26-gigapixels.com/en/
ОС выше указал. Как-то сглупил и не придал этому значения.
Софт — PTGui. Но толку? Он все равно закрыт. Нормальных бенчмарков по нему нет.
Я видел табличку сводную, которую сообщество ведет уже несколько лет, но это просто пузомерка «железо — время».
Аutopano giga мне не нравится интерфейсами. Да и… тормознее пятигуя он. Процентов на 20.
Релиз по Парижу, обоим Лондонам и некоторым другим — я читал. Чуть ли не дословно их помню.
Описанный пример (на описанном железе) я прогонял по 6 раз в день.
Мне в ближайшее время предстоит сшивать панораму на 160 гигапикселей. Вот и пытаюсь понять каков оптимальный конфиг.
Вопрос был про кэши и теории объяснения наблюдаемого явления.
Ну врядли кто-то Вам выдвинет теорию на основании этих скудных фактов.
Обычно в подобном ПО есть много рычагов настройки, число потоков, использование GPU, размеры кэшей и т.п. Нада просто их перебрать экспериментально.
По поводу разницы 6-8 ядер, посмотрите на каких реально частотах работают CPU при рендеринге.
Просто с турбобустом не все так очевидно, 2660 при полной загрузке 8 ядер работают на 2.7ГГц, а при неполной на 2.8-2.9, вот и нету например разности 12 ядер на 2.8 ГГц и 16 ядер на 2.7ГГц.
Ну, к сожалению, более полных фактов нет.
Еще с CPU-Z сниму данные по частотам. И все, пожалуй.
Особых рычагов нет ни в PTGui ни в Аutopano giga.
Можно лишь искусственно ограничить число потоков (к примеру, пятигуй видит 16 ядер и 32 потока, а я могу ему задать меньшее число).
Кэши — лишь «на каком томе складывать их».
На GPU эти операции не считаются и не будут считаться в будущем (инфа от авторов софта).
Короче говоря, я перебрал все, что смог. Данные выше.
Завтра еще коллега озвучит результаты теста для i7-3820. Будет ли там зависимость от числа активных ядер и потоков.
Меня просто поразило, что 12 ядер с точностью до погрешности измерения (!) равны в производительности 16 ядрам.
Вот и показалось, что все упирается в некий ресурс, которого хватает лишь на 6(12), а не 8 (16).
Еще все может радостно в шину памяти. Еще может упираться в шину между процессорами. Еще, как сказали выше, турбобуст очень много может менять, сам такое наблюдал.
По идее, кэш L3 должен на все ядра делиться (кроме размера L2+L1 наверное), остальные уже каждому ядру свои.
Маленький коммент, перенесите описание слова варп выше, дабы сразу было понятно, что имеется в виду.
Можно понизить частоту памяти и смотреть, что произойдет. Еще можно попробовать смотреть на частоты во время работы. С кэшем сложнее. Еще можно вытащить один процессор и посмотреть что будет. Во сколько раз упадет производительность. Если менее чем в 2, скорее всего шина между ними виновата.
В конфигурациях 16 ядер + НТ, 16 ядер, 12 ядер при сшивке все одно и то же — процессор загружен «почти полностью» (порядка 90% по показаниям венды), частота — строго 2200мгц, т.е. номинальная. Это уже по данным CPU-Z (попутно выяснилось, что процессор не 2660, а 2670).
Какой вывод из этого следует?
PS
Понизить частоту искусство не получается — в биосе нет опций.
Выводы, что-то аппаратно работает явно не так или CPU-Z врет.
У 2670 номинальная частота 2.6ГГц, с турбобустом при полной загрузке должен работать на 3ГГц, при неполной на 3.1-3.3ГГц.
2.2ГГц это номинал как раз для 2660.
Проверить легко -любой новый живой linux + i7z утилита.
Если CPU-Z не врет, то скорее всего или несовместимость CPU и материнки, или глюки ОС.
Ну и странно, что нет настроек турбобуст и частот, хотя на серверных могли и такое учудить…
Боюсь, с инженерным образцом что-то советовать нету смысла.
Хотя по логике, и частота в названии и значения множителей (12-33) отвечают нормальному процессору.
Откуда при нагрузке вылезло 2.2ГГц непонятно.
Может установлен принудительно какой-то сберегающий режим работы?
Чтобы исключить ОС, загрузите любой linux live + соберите i7z.
А, ну так если разные камни, то неудивительно что работают на частоте наименьшего + не включается турбобуст :-)
Вообще-то неудивительны и странные результаты работы программ :-)
Оставте один 2670 и прогоните все тесты и CPU-Z.
На такой кривой системе результаты получить достоверные трудно :-)
Да, будем по отдельности проверять как там 6 или 8 ядер.
Система… ну лучшее из доступного. Я коллеге итак очень благодарен за эту возможность. Другой не было.
Хохма еще в том, что я все через IPMI делаю, с фпс 0-1 :)
