Перейти к публикации

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


Рекомендованные сообщения

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

Появился интересный вопрос по работе 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.

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

 

 

 

 

 

 

 

Ссылка на сообщение
Поделиться на других сайтах


UnPinned posts
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?

 

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

Изменено пользователем AlexKaz
Ссылка на сообщение
Поделиться на других сайтах
40 минут назад, MaximKl сказал:

в режиме SMP

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

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

Изменено пользователем AlexKaz
Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

 

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

 

Изменено пользователем a_schelyaev
Ссылка на сообщение
Поделиться на других сайтах
2 часа назад, AlexKaz сказал:

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

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

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

Ссылка на сообщение
Поделиться на других сайтах
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 - не очень коррелируется с предположением об недостаточности пропускной способности.

 

 

 

Изменено пользователем MaximKl
Ссылка на сообщение
Поделиться на других сайтах
45 минут назад, MaximKl сказал:

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

 

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

Цитата

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

 

Ссылка на сообщение
Поделиться на других сайтах
2 часа назад, MaximKl сказал:

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

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

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

 

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

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

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

 

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

 

 

 

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

 

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

Ссылка на сообщение
Поделиться на других сайтах

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

Ссылка на сообщение
Поделиться на других сайтах
21 час назад, a_schelyaev сказал:

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

 

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

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

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

Ссылка на сообщение
Поделиться на других сайтах
4 часа назад, MaximKl сказал:

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

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

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

Ссылка на сообщение
Поделиться на других сайтах
  • 7 месяцев спустя...
Солнечный энергетик

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

 

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

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

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

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

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

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

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

Ссылка на сообщение
Поделиться на других сайтах

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

Ссылка на сообщение
Поделиться на других сайтах
51 минуту назад, Fedor сказал:

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

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

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

Ссылка на сообщение
Поделиться на других сайтах
1 час назад, Fedor сказал:

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

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

Ссылка на сообщение
Поделиться на других сайтах
1 час назад, AlexArt сказал:

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

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

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

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

Ссылка на сообщение
Поделиться на других сайтах
4 минуты назад, soklakov сказал:

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

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

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

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

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

Ссылка на сообщение
Поделиться на других сайтах
3 минуты назад, AlexArt сказал:

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

Не совсем.

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

Ссылка на сообщение
Поделиться на других сайтах
Солнечный энергетик

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

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

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

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

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

Ссылка на сообщение
Поделиться на других сайтах

Присоединяйтесь к обсуждению

Вы можете опубликовать сообщение сейчас, а зарегистрироваться позже. Если у вас есть аккаунт, войдите в него для написания от своего имени.
Примечание: вашему сообщению потребуется утверждение модератора, прежде чем оно станет доступным.

Гость
Ответить в тему...

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

  Разрешено не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.

  • Сейчас на странице   0 пользователей

    Нет пользователей, просматривающих эту страницу.




  • Сообщения

    • gudstartup
      а вы хоть станок проверяли по программе на изделии на точность прежде чем товарищей этих выгнать? если нет то грешите на самих себя! система в наших краях еще не распространенная поэтому и тем тут нет надо в поднебесную писать
    • AlexArt
      Ну допустим, ты и на другом ресурсе это опубликовал. А не коммуниздил. Но вот продвигать воровство от государства, ворующее из Вики, это верх мерзости.
    • maxx2000
      Ах, да. Фильтры выбора добавили. Теперь можно выбрать только то что видно на первом плане, а не вместе с тем что с обратной стороны детали. В общем надо обновляться. Как раз работёнка на прессформу нарисовалась 
    • maxx2000
      Причина того - Кроилово. Кроилово всегда приводит к попадалову. Месяц простоял сколько мильонов деревянных потеряли? Вопрос риторический. И ещё будет стоять. Как памятник человеческой глупости и жадности.
    • AlexKaz
      "9 июля 1968 года на мышах был проведен самый знаменитый эксперимент американского ученого-этолога Джона Кэлхуна «Вселенная-25». Суть опыта заключалась в создании идеальных условий, где мыши могли бы жить и размножаться, не ведая никаких забот, вдали от хищников и в отсутствие эпидемий и заболеваний. Для этих целей ученый построил специальный загон, куда были помещены четыре пары белых мышей (самцов и самок). В распоряжении мышей всегда была чистая вода и еда в изобилии, специальные гнезда, где можно обустроить себе жилище ― гнезд в загоне хватало для проживания нескольких тысяч мышей. Температура в загоне в среднем составляла около 20 ℃ и была комфортной для мышей. Животные не подвергались никаким влияниям извне и жили в идеальных условиях в свое удовольствие. А дальше началось самое интересное. На первом этапе эксперимента мыши хорошо размножались, вели активный образ жизни, охотно играли. На следующей фазе эксперимента мыши стали есть меньше, перестали наедаться до отвала. На третьей фазе эксперимента, когда в загоне были уже сотни мышей, произошло распределение социальных ролей, стала ярко выраженной иерархия, клановость. Появились так называемые отверженные ― молодые особи, которых другие, взрослые мыши сгоняли в центр загона, не давали им вести нормальный образ жизни, причиняли физический вред. В природе такое, наверное, было бы невозможно, ведь эти мыши-агрессоры просто не дожили бы до старости: их бы съели хищники. Но в загоне Кэлхуна хищников не было, и взрослые мыши начали попросту издеваться над молодняком. Образовались две большие группировки: самцы-одиночки и самки-одиночки. При этом самки-одиночки отказывались спариваться <с менее статусными многочисленными молодыми самцами и с оставшимися старыми статусными> и отвергали ухаживания самцов. У мышей стал проявляться тотальный индивидуализм, мыши не стремились создать семью. На последней, четвертой стадии мышиная популяция стала сокращаться. Появились самцы, которых сам Кэлхун назвал «красивыми» (англ. beautiful ones), из-за отсутствия ран и рубцов. <В оригинале: They never engaged in sexual approaches toward females, and they never engaged in fighting, and so they had no wound or scar tissue. Thus their pelage remained in excellent condition. - Дословный перевод: Они никогда не прибегали к сексуальным подходам к самкам, и они никогда не участвовали в боях, и поэтому у них не было ран или рубцовой ткани. Таким образом, их шерсть сохранилась в отличном состоянии.> Эти мыши не вступали в борьбу за самок и территорию, не проявляли активности к размножению и только питались, спали и чистили шёрстку. У мышей стали проявляться различные формы девиантного поведения, вспышки агрессии. Самки стали проявлять агрессию, защищать себя сами, стали умерщвлять своих детенышей, а затем окончательно отказались размножаться. На пике эксперимента в загоне одновременно проживало чуть более двух тыс. мышей. Еды и гнезд было достаточно для дальнейшего роста популяции, но через четыре года после начала эксперимента Кэлхун остановил свой опыт, потому что в загоне осталось чуть более сотни мышей, и все они уже вышли из репродуктивного возраста. По итогам эксперимента Кэлхун пришел к выводу, что достижение определенной плотности населения и заполнение социальных ролей в популяции приводит к распаду общества" https://physicsoflife.pl/dict/pic/calhoun/calhoun.. https://scientificrussia.ru/articles/utopiya-dlya-mys.. https://ru.wikipedia.org/wiki/Кэлхун,_Джон_(этолог)
    • gudstartup
      @Koels вот в чем дело пока ds609 это предупреждение поэтому F может и не появится если sv601 это значит ошибка. возможно при нагреве радиатора серво определяет это как предупреждение или ваш вентилятор крутиться медленнее чем оригинальный и серва думает что он встал хотяпри этом обычно на экране в строке состояния FAN.мигает больше у меня вариантов нет....  
    • ДОБРЯК
      Решите любым алгоритмом. Тогда будет конструктивный разговор. :=)
    • Fedor
      https://en.wikipedia.org/wiki/List_of_numerical_analysis_topics#Eigenvalue_algorithms     :) 
    • Юрий К.Ф.
      Добрый день. Не нашёл тут тему по стойке Китайско Китайской)) Lynuc N3ME. Видать мне так повезло с её наличием)) Приобрели 5-ти осевой Китаец. В б/у состоянии после удара по оси Z. Отремонтировали по механике, заменили батареи на драйверах, выставили лимиты. Всё Ок. Пригласили со стороны людей которые бы разобрались по операторской части. Те два выходных ковырялись, после сказали покажут расскажут, но за огромные деньги. Не сошлись. После месяц станок простоял, когда включили перестал реагировать на регулировку скорости шпинделя. То есть в режиме Jog, включаем обороты, которые стандартно 2140-2149 об/мин. При регулировке процетности не меняются (сама процентность показывает на мониторе). Так же при включении оборотов через команду M03S300 или другое значение, скорость так же показывает 2140-2149 об/мин. Грешить на тех товарищей с которыми не сошлись по деньгам для обучения, как то не хочется. Поковырялся в настройках шпинделя, вроде всё в норме. Проводку на шпинделе прозвонил, целая. В чём причина, не понятна. Кто нибудь сталкивался с подобным, или с подобной стойкой? Может подсказать варианты причины подобного?
    • ДОБРЯК
×
×
  • Создать...