ANSYS - вопросы производительности на двухпроцессорной системе

[MaximKl 8]

Здравствуйте!

Появился интересный вопрос по работе ANSYS 2021R2 по работе на многопроцессорной конфигурации - возможно, кто-то сталкивался с таким....

 

Итак, появилась возможность попробовать работу ANSYS Mechanical на двухпроцессорной китайской материнке Х99-F8D.

Машина 1:

На борту материнка имеет 2 процессора XEON E5-2696v3 - 2x18 ядер 2.3GHz.

Соответственно:  2 проца - 2 набора памяти, общим объемом 32Gb

 

Все китайское железо сравнивалось более современной машиной с конфигурацией:

Машина 2:

CPU - i7-10700KF( 8 ядер, 3.8GHz)

RAM: 128Gb...32GB - чисто для сравнения пробовали разный объем.

 

Во всех случая был выключен Hyper-threading - соответственно речь выше  шла о физических ядрах процессоров.

Сводка по результатам сравнения:

Сравнение производительности.pdf

 

 

Коротко, все работы сводятся к следующему:

На машинах 1 и 2 попеременно проводятся одни и те же расчеты в Mechanical, фиксируется статистика и расход ресурсов.

 

И после обработки результатов возникает странная ситуация:

 - двухпроцессорная конфигурация имеет существенный проигрыш по скорости выполнения расчетов.

Причем, на скорость напрямую влияет операционная система - Win2016server /Win10Pro: 3h11min / 42min

 

Та же задача, решаема на машине 2, решается за 16минут :)

 

Причем, количество памяти роли не играет - в режиме SMP, где и проводились все расчеты, расход памяти примерно одинаковый 15...17Gb, т.е. решатель никогда не упирался в ограничение и в режим out-of-core не переходил.

 

 

Но, при всем этом,на машине 1 по сводке ANSYS имеет место быть просто дикий объем считанной/записанной информации, опять таки,сильно зависящий от операционной системы: Win2016server/Win10Pro : 2.7Tb/0.5Tb

 

На машине 2, этот объем не превышает 0.3Tb - сколько ты в ней не было памяти 128 или 32Gb.

 

 

Дальше зависимость еще интереснее:

Если на машине 1(36 ядер) использовать для расчета только 18 или менее(пробовали 8), то скорость расчет еще более возрастает :(36 ядер/18/8): 42/30/24мин.

Сразу оговорюсь  - нет, частота проца здесь роли не играла:  при задействовании такого числа ядер частота 2.7GHz по всем используемым ядрам.

 

 

Вопрос, собственно, чисто для развития:

 

 - использование многопроцессорных вычислений HPC - миф, или реальность? 

Даже не так: HPC кроме масштабируемости, обладает потерей производительности как платой за эту возможность?

 

- за счет чего возникает значительный объем внутренней информации при использовании ANSYS MECHANICAL на многопроцессорной материнке?

-почему этот объем внутренней информации снижается при урезании числа ядер для расчета и время расчета сокращается?

- Windows-based системы - не самые оптимальные для HPC?

 

P.S.

Вопросы эти задавались уже людям как  пользующим, так и  администрирующим кластеры с ANSYS.

Пока никакой версии - почему так- не выявлено - вопрос просто не ставился в таком ключе.

 

 

 

 

 

 

 

[AlexKaz 1 823]

24 минуты назад, MaximKl сказал:

- за счет чего возникает значительный объем внутренней информации при использовании ANSYS MECHANICAL на многопроцессорной материнке?

В BIOS измените настройки:

- NUMA on или off и разные вариации NUMA. при NUMA on межъядерный трафик с mpi должен упасть на порядки

- Chip on Die (CoD) on или off

- явно ручками задайте скорость QPI

24 минуты назад, MaximKl сказал:

XEON E5-2696v3

он разлочивается. народ вырубает ядра и оставляет 10 чтобы работать при 3.8 ГГц по всем. этого хватает и на сильный однопоток, и  на загрузку 4 принадлежающих CPU каналов оперативки. кстати, на сборке должна быть практически линейная зависимость роста скорости счёта до 8*2 числа потоков т.к. рабочих каналов должно быть 8 (4+4)

24 минуты назад, MaximKl сказал:

HPC кроме масштабируемости, обладает потерей производительности как платой за эту возможность?

решатель то какой? distributed через MPI?

 

Ну и задачи разные бывают, проверьте и на мелкой сетке линейную статику без трения и модальный.

Изменено 23 июля 2022 пользователем AlexKaz

[AlexKaz 1 823]

40 минут назад, MaximKl сказал:

в режиме SMP

ls-dyna что ли? Ну, ещё б оно на старом Xeon не тормозило. Только MPP для этих машинок ещё и можно заюзать.

Сразу пишу, в MPP на крупных задачах этот древний монстр уделает любой Ryzen 5000 и Intel 12000 с ddr4 в 3-4-5 раз. Не говоря уже про доступный объём оперативки. В SMP да, всё очень тускло. Да и не параллелит dyna свой SMP-решатель больше чем на 8 потоков...

Изменено 23 июля 2022 пользователем AlexKaz

[a_schelyaev 366]

Для начала нужно почитать что сами разработчики пишут про свой решатель и рекомендации. Если использовать MPI то параметр Numa нужно в нужное положение задать - 20% выиграете на пересылках данных между процессорами в память каждого. Далее размер задачи в памяти. Если у вас оно свопит на диск, то значит памяти не хватает - алгоритм может запрашивать почему-то больше для конкретного метода расчета. Если задача сама по себе большая и вы грузите все ядра, то в районе 8 ядер кривая ускорения внутри ЦП ложится на полку, если не раньше. Селяви. Виноват канал памяти - его пропускная способность.

Проверьте сперва каждый ЦП на скорость начав с маленькой задачи на одном ядре. Увеличивайте размер задачи и получите для него зависимость. Потом увеличивайте количество ядер, потом опять размер задачи. Так вы увидите когда канал памяти даст о себе знать.

Предположу, что режим макс скорости для вашей новой системы будет запуск в два ЦП по половине ядер на каждом.

И не забудьте глянуть на лог чтобы увидеть сколько каждый ЦП времени тратит на шаг расчета - нужна ли балансировка?

 

А для Серверной ОСи поставьте Cluster Pack или HPC Pack , в который входит MSMPI который умеет коротким путем по сети ходить. Если его Дайна поддерживает.

 

Изменено 23 июля 2022 пользователем a_schelyaev

[MaximKl 8]

2 часа назад, AlexKaz сказал:

ls-dyna что ли? Ну, ещё б оно на старом Xeon не тормозило. Только MPP для этих машинок ещё и можно заюзать.

Сразу пишу, в MPP на крупных задачах этот древний монстр уделает любой Ryzen 5000 и Intel 12000 с ddr4 в 3-4-5 раз. Не говоря уже про доступный объём оперативки. В SMP да, всё очень тускло. Да и не параллелит dyna свой SMP-решатель больше чем на 8 потоков...

Вообще ниразу не LS-DYNA - STATIC STRUCRUTAL.

[MaximKl 8]

27 минут назад, a_schelyaev сказал:

Для начала нужно почитать что сами разработчики пишут про свой решатель и рекомендации. Если использовать MPI то параметр Numa нужно в нужное положение задать - 20% выиграете на пересылках данных между процессорами в память каждого. Далее размер задачи в памяти. Если у вас оно свопит на диск, то значит памяти не хватает - алгоритм может запрашивать почему-то больше для конкретного метода расчета. Если задача сама по себе большая и вы грузите все ядра, то в районе 8 ядер кривая ускорения внутри ЦП ложится на полку, если не раньше. Селяви. Виноват канал памяти - его пропускная способность.

Проверьте сперва каждый ЦП на скорость начав с маленькой задачи на одном ядре. Увеличивайте размер задачи и получите для него зависимость. Потом увеличивайте количество ядер, потом опять размер задачи. Так вы увидите когда канал памяти даст о себе знать.

Предположу, что режим макс скорости для вашей новой системы будет запуск в два ЦП по половине ядер на каждом.

И не забудьте глянуть на лог чтобы увидеть сколько каждый ЦП времени тратит на шаг расчета - нужна ли балансировка?

 

А для Серверной ОСи поставьте Cluster Pack или HPC Pack , в который входит MSMPI который умеет коротким путем по сети ходить. Если его Дайна поддерживает.

 

Повторюсь - это STATIC STRUCTURAL, не дайна.

Про NUMA мысль была - но пока не поигрались с этим. Мнения противоречивые, но до 20% не встречал. Проверим и это.

Смущает другое - зависимость скорости от операционки. Причем в разы.

 

Повторюсь, машина с зеонами не свопит при расчетах - память занята максимум на 67% - это в SMP.

Если 36 ядер юзать в режиме DMP - то да, 32GB не хватает - видать,особенности распараллеливания.

Пробовали и разные решатели - и DIRECT и итеративный - сильно прогресса нет.

 

По памяти, чтобы было понятнее - на двухголовых зеонах - стоят 4-хканальные контроллеры памяти, на i7-  двухканальные. В конце сравнительного файла есть табличка по тестам AIDA64 - память на зеонах раза в 2 быстрее, чем на i7 - не очень коррелируется с предположением об недостаточности пропускной способности.

 

 

 

Изменено 23 июля 2022 пользователем MaximKl

[AlexKaz 1 823]

45 минут назад, MaximKl сказал:

Смущает другое - зависимость скорости от операционки. Причем в разы.

 

На спецфоруме обсуждался глюк: некоторый single thread софт сильно просаживал скорость на WinServer 20** какой-то там. Так что да, бывало и такое.

Цитата

оказалось, что 33% времени микрокап проводит в SysWow64/win32u.dll, это прокладка между юзерспейсом и кернелом.

 

[a_schelyaev 366]

2 часа назад, MaximKl сказал:

Повторюсь - это STATIC STRUCTURAL, не дайна.

Про NUMA мысль была - но пока не поигрались с этим. Мнения противоречивые, но до 20% не встречал. Проверим и это.

Смущает другое - зависимость скорости от операционки. Причем в разы.

 

Повторюсь, машина с зеонами не свопит при расчетах - память занята максимум на 67% - это в SMP.

Если 36 ядер юзать в режиме DMP - то да, 32GB не хватает - видать,особенности распараллеливания.

Пробовали и разные решатели - и DIRECT и итеративный - сильно прогресса нет.

 

По памяти, чтобы было понятнее - на двухголовых зеонах - стоят 4-хканальные контроллеры памяти, на i7-  двухканальные. В конце сравнительного файла есть табличка по тестам AIDA64 - память на зеонах раза в 2 быстрее, чем на i7 - не очень коррелируется с предположением об недостаточности пропускной способности.

 

 

 

Итерационные решали меньше кушают памяти обычно, нежели приямая. На DMP удельный объем памяти на каждый узел/ЦП ниже - задача же пилится.

 

Пока вы описываете какой-то треш.

[AlexKaz 1 823]

Кстати, вспомнилось, что за пару лет за счёт внесения защит от Meltdown Haswell'ы без отключения патчей просаживаются на несколько десятков процентов в виртуалках. Патчи в основном  есть свежие микрокоды. А винда принудительно при загрузке заливает свежий микрокод.

[MaximKl 8]

21 час назад, a_schelyaev сказал:

Итерационные решали меньше кушают памяти обычно, нежели приямая. На DMP удельный объем памяти на каждый узел/ЦП ниже - задача же пилится.

 

Пока вы описываете какой-то треш.

Задача пилится, но, требуется синхронизация между узлами - за счет этого память и кончается....

То, что треш - согласны и люди из службы ИТС -  если бы результаты не были  продемонстрированы лично. 

[a_schelyaev 366]

4 часа назад, MaximKl сказал:

Задача пилится, но, требуется синхронизация между узлами - за счет этого память и кончается....

То, что треш - согласны и люди из службы ИТС -  если бы результаты не были  продемонстрированы лично. 

Синхронизация не требует серьезного роста памяти, если конечно же разработка через одно место алгоритм не сделала.

[Солнечный энергетик 1]

У меня примерно также вел себя COMSOL при расчете на двухпроцессорной системе. 12  ядер 2650 V4 два процессора. Быстрее его считал новый I5-10400. 

 

Потом был еще расчет на STAR CCM тяжелой модели.  На STAR-CCM с процессором LGA2011 старым 12 ядер производительность суммарная вышла сопоставимо с 24 ядрами. 

Получилось обеспечить памяти больше на старом процессоре, и хотя там DDR3, расчет быстрее шел чем много ядер/меньше памяти. 

Если полностью вся модель может в оперативной памяти развернутся, без свопов на диск и прочих операций, скорость расчета растет. 

Наблюдения показали, что даже старый LGA2011 процессор прилично тратит времени на выборку, суммарный расчет не всегда дает загрузку на 100% ядер.  

Не знаю такие операции как или сортировки или решения уравнений в матрицах лимитируют.  С использованием более современных процессоров эти скорости примерно в 2-3 раза выше,

и суммарное время расчета уменьшается, сам процессор общий счет ведет на частоте более 4ГГц. 

Из-за свопа на диск у меня умер SSD на 18 день счета...   Упрощенная модель на 16 ядрах 4Ghz+ минимальной сеткой дала расчет за полтора часа. С усложненной сеткой (с детализацией по мелким элементам) - она же, расчет сошелся за сутки.  

[Fedor 1 597]

Если задачка потребовала больше времени чем надо чтобы выкурить сигарету или выпить чашечку кофе, значит она плохо сформулирована. :) 

[AlexArt 278]

51 минуту назад, Fedor сказал:

Если задачка потребовала больше времени чем надо чтобы выкурить сигарету или выпить чашечку кофе, значит она плохо сформулирована. :) 

Соглашусь. Но чтобы она так быстро считалась нужно прежде всего затратить существенное кол-во времени на её упрощение.

Хотя, как показывает мой опыт, задачу всегда надо упрощать до максимума.

[Fedor 1 597]

Так головой работать надо, заметил заяц выходя от слонихи :) 

[karachun 2 038]

1 час назад, Fedor сказал:

Если задачка потребовала больше времени чем надо чтобы выкурить сигарету или выпить чашечку кофе, значит она плохо сформулирована. :)

В вычислительной газодинамике это не работает.

[soklakov 1 475]

1 час назад, AlexArt сказал:

Хотя, как показывает мой опыт, задачу всегда надо упрощать до максимума.

Ещё лучше не упрощать, а сразу брать кубик,балку, цилиндр. А вот их уже усложнять, пока желаемая точность не достигнута.

Хотя... Это все хорошо, когда знаешь, что хочешь получить.

Если моделирование "чтобы заглянуть внутрь неизвестного", то придется сначала все детали включать, ведь неизвестно, какие из них  не нужны.

[AlexArt 278]

4 минуты назад, soklakov сказал:

Если моделирование "чтобы заглянуть внутрь неизвестного", то придется сначала все детали включать, ведь неизвестно, какие из них  не нужны.

Вопрос в опыте расчетчика.

17 минут назад, karachun сказал:

В вычислительной газодинамике это не работает.

Работает. Сами же неоднократно рассказывали, что деталь с мелкими отверстиями можно заменить на пористую модель что ли или как там?

[soklakov 1 475]

3 минуты назад, AlexArt сказал:

Вопрос в опыте расчетчика.

Не совсем.

На то оно и "неизвестное", чтобы с опытом не перекликаться.

[Солнечный энергетик 1]

Есть режим робот - бери считай по шаблону. Но сколько других вариантов, когда сетка с изъянами, потом расчет не сходится, когда немного покрутил в зону побольше чисел рейнольдса, и то что должно было посчитаться уже никогда не посчитается.

Как  то была модель аппарата построена, сетку сформировали. Ну да много элементов вышло... больше 10млн.
Запустили на расчет - все сходится, просто большая область. Сидеть и ждать...  побольше ядер и ждите.
Два раза отключение света - не дали досчитать более трети расчета. Уже с другим UPS пошел расчет - сбойнула память. Еще разок останов через 5 дней. 

Запустил последний раз с другим комплектом памяти, носитель SSD - все бодро пошло, итог 5 раза - на 18 сутках расчета сдох SSD. 

Потратил прилично времени, создав модель абсолютно уже с нуля. Первый прототип с упрощенным в шесть раз меньше элементов - сосчитался в грубом приближении за 1,5 часа.

Для этого правда пришлось еще десктоповский проц заиметь последних моделей.  После схождения расчета - крутилки перевел в детализации повыше (т.к. есть элементы которым отдельное внимание).  За сутки модель сосчиталась.