[Hale 1]

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

Операции на огромных матрицах которые производит метод FEM требуют гигантской производительности памяти. Четырехканальный процессор почти удваивает производительность своей "игровой" двухканальной версии. А чтобы чтения памяти удвоенного размера и поспевали и не толкались перед конвейером, нужен увеличенный кеш Ксеона. Но конечно такие обхемы как в процессорах Xeon Platinum - ни к чему.Да они и медленнее чем W-серия. Я полагаю, что для всех ECC Xeon-ов интел подбирает размеры кеша адекватно задачам, так что не ломайте лишний раз голову.

 

>. У интела для того чтобы насытить 4-х канальный контроллер памяти

бред сивой кобылы. скорее всего основан на тестах производительности в играх. Векторные операции последних лет вообще могут сосать память как пылесос. Ансис утверждает что в этом плане они идут в ногу со временем, даже где-то публиковали какие компиляторы используют.
Я не проверял, кстати, но судя по всему HFSS 2021 наконец может развернуться на платформе Zen3 во всю мощь.

Наилучшую производительность как ни странно можно получить на процессорах i7 Extreme. Но в них по моему кастрирован ECC и мониторинг сбоев, отсутствует и термальная балансировка памяти. Именно отсутствие буфера кстати ускоряет работу с памятью и делает машину непригодной для большого бизнеса - сбои слишком дорого обходятся.

 

По поводу многоядерности - с годами ситуация менялась. До версии 2015 года ХФСС очень хорошо масштабировался по количеству ядер до 8 штук. Но новый ХФСС (главный решатель) обладая большей производительностью на ядро, почти не масштабируется больше 2 ядер. Прирост от 4, х8 ядер будет то появляться то исчезать в зависимости от решаемой модели, и на очень короткое время. Кроме того есть подозрение, что это искуственное ограничение базовой лицензии без множественных параметрических опций, чтобы пользователи не получали большой производительности оптимизируя в одну задачу через Matlab и скрипты, тогда как параметрика позволяет параллелить вариации. Косвенно это подтверждается тем что в версии 2021 окончательно была вырезана старая функция "неблокирующего" запуска решения присутствовавшая там с версии 9 по моему и позволявшая худо-бедно параллелить через скрипт.

В сухом остатке для промышленных задач вам надо кластер из 4-6 -ядерных 4-канальных машин с максимально возможными клоками на ECC памяти и очень большой пакет HPC лицензий.... если вы работаете советским методом, не забывайте отключить все это от интернета, зашифровать диски и не выносите проекты наружу иначе как в виде конечных чертежей.

 

Избегайте десктопных рабочих станций Делл - их дохлые материнки не позволяют крутиться процессорам W-серии на полной мощности. Лучше собирать станцию самому на широко-конфигурируемом железе, изучив какую мощность могут выдавать набортные стабилизаторы VCC просессора

 

P.S. многопроцессорные станции противопоказаны из-за большого пенальти между NUMA нодами.

 

Про GPU - Ansys много врет и много делает для галочки. Их презентации отчасти стали фуфлом. Из того что я погонял, понял что GPGPU включается только на моделях с простыми материалами, дефолтный металл, изотропный диэлектрик. Только для Транзиент и Дривен модал солверов.

Если есть хоть один кусочек анизотропного материала, или какие-то нестандартное ГУ - GPGPU код отключается. (PML не пробовал, забыл)
С версии 2020 если ускоритель не из списка поддерживаемых  - GPGPU код отключается. Тут видимо какой-то маркетинговый заговор с nVidia,  потому что это ограничение искусственное и в более ранних версиях все работало даже на Geforce.

Из собственных экспериментов, полосковые делители мощности на изотропной подложке одна Quadro RTX 5000 ускоряет наверное раз в 5 по сравнению с современных 8-ядерным W-xeon, а может и больше.

 

[Hale 1]

З,Ы.

Про параметрические свипы. В версиях 2020 и 2021R1 наложены безумные ограничения на параметрику. Для задействования 2 параметрических задач в параллеле (свипы) вам потребуется АЖ 16(!) HPC лицензий. Обещали вдвое уменьшить требования на параметрику в версии 2021R2, видимо народ их засыпал кирпичами.

>Есть специализированные машины, именно для продуктов ANSYS, не только для HFSS
маркетинговое фуфло в основном для университетов и постеров, сколько мы смогли залупить ядер в кластер бульдозеров. То что я видел - решения менее оптимальные чем офисный i5; преимущество обычно только в блейд-сборке под ключ. Короче, для ленивых.

[Freesom 15]

41 minutes ago, Hale said:

>. У интела для того чтобы насытить 4-х канальный контроллер памяти

бред сивой кобылы. скорее всего основан на тестах производительности в играх. Векторные операции последних лет вообще могут сосать память как пылесос.

Не-а, он основан на гайдах HP по использованию пролиантов. Но, не спорю, это конечно тяжко для понимания тем, кто кроме игр особо ничего не видел.

[Hale 1]

И что же вы запускаете на серверах пролиант? Веб, или геймсервер? Кончайте этот бред, честное слово. Это задаче-ориентированные тесты и никто на серверной платформе не гоняет ни многопоточный BLAS ни тем более чисто-матричные задачи, которые в конечном итоге сводятся к последовательному перекладыванию локальных данных. Память - это не port-io, с ondie контроллерами нет боттлнека процессора. Ботлнек появляется на NUMA, и тем более при на FSB процессорах. А на SP Xeon, чем меньше ядер - тем дальше боттлнек. При грамотном программировании все читается с той скоростью с которой контроллер может высосать из модулей, с потолком примерно на пропускной кеша. А вот вопрос в пригодности программирования разнообразных серверов и I/o-ориентированного софта, это другое дело. Процессор может выполнять столько порожней работы, что простои и насыщение там не за горами.

 

кстати, простой эксперимент. запускаем testmem5 на 4-канальной машине в 2,4,6,8 потоков. Сами тесты поддерживают оптимизацию до 2 каналов, но это только оптимизация тестирования. Загрузку по каналам распеределяет не тест а операционка с процессором по количеству потоков. Видим что никакого насыщения нет, в Lines и тетрис можно продолжать играть без тормозов, можно даже blas тестирование с короткими задачами запускать. А вот веб браузер будет ожидаемо тупить с подгрузкой картинок.

[Pubzor 0]

Спасибо всем. Буду ориентироваться на советы.
Речь про фермы не шла. Нужен лишь ПК по мощнее, а в ступор загнали непонятки с памятью.

[Freesom 15]

4 hours ago, Hale said:

Это задаче-ориентированные тесты...

простой эксперимент. запускаем testmem5 на 4-канальной машине в 2,4,6,8 потоков. Сами тесты поддерживают оптимизацию до 2 каналов, но это только оптимизация тестирования. Загрузку по каналам распеределяет не тест а операционка с процессором по количеству потоков.

Нет, для измерения пропускной способности памяти (с учётом векторизации или без) традиционно берётся STREAM triad benchmark, а количество задействовнных ядер ограничивается в биосе. Тогда тесты будут отражать реальность, а софтовые потоки это ни о чём. И неважно кто делает тест, интел, HP, Dell или сам пользователь - платформа одинаковая и результаты будут такие же.

16 hours ago, Hale said:

Векторные операции последних лет вообще могут сосать память как пылесос. Ансис утверждает что в этом плане они идут в ногу со временем, даже где-то публиковали какие компиляторы используют.

Вот однопроцессорные Broadwell E5-2697 v4 (BDW) против CascadeLake Gold 6248 (CLX). Да, у CascadeLake контроллер памяти 6-канальный и насыщается он уже 14-ю ядрами, не зависимо от того скалярные или векторные инструкции применены, так что компиляторы не помогут. У Broadwell векторные AVX2 выводят контроллер в насыщение уже на 8 ядрах, а не 10, но FEM, во всяком случае у CST, использует AVX2 только на коротком подготовительном этапе расчета (всегда упираясь в TDP проца), так что AVX2 тоже не спасает - это тема T-солвера.

Spoiler

 

 

1 hour ago, Pubzor said:

Нужен лишь ПК по мощнее, а в ступор загнали непонятки с памятью.

Не знаю почему Ansys не выдал понятных рекомендаций пользователям, но можете смело использовать советы от CST:

[Hale 1]

>а софтовые потоки это ни о чём

воблин. Дожили. И софтовый решатель HFSS тоже ни о чем. Живем в своем выдуманном мирке, где потоки сами параллелятся и конкурентно сами с собой память читают видимо.

Ну ограничивайте через биос, хардово. Я вам по секрету скажу, и в лине и в виндоуз10 ядра можно софтово отключать... так к слову, чтоб не заставлять вас перезагружаться.

>насыщается он уже 14-ю ядрами,

Еще раз об этом бреде насыщения. Упомянутое насыщение может происходить только в трех случаях 1) Если у вас медленная шина FSB между процессором и контроллером памяти 2)Если у вас пропускная кеша ниже пропускной контролера памяти 3)Если у вас пропускная конвейера самого процессора ниже пропускной памяти. А поскольку дефакто ответ на все три пункта - НЕТ-НЕТ-НЕТ, то любое "насыщение" может быть связано только с особенностями софта. Симуляторный софт во время решения по природе активным IO не занимается, а в частности активно использует SIMD инструкциии чтобы уменьшать оверхед.

 

>Не знаю почему Ansys не выдал понятных рекомендаций пользователям, но можете смело использовать советы от CST:

Странные советы. По крайней мере для HFSS

1)"96Gb RAM per CPU", подразумевает multi-CPU. А этого надо избегать любой ценой. Автоматика в ОС рано или поздно закинет кусок данных на соседний нод NUMA и тогда получите падение производительности на 15% сходу. А на SP просто без разницы - берете столько памяти сколько вам надо под задачу.

2)"The fastest RAM", а вот Freesom не согласен. Freesom утверждает что память там насыщается, и нет смысла ее ускорять не используя больше 14 ядер. И чему верить? ну и остальной текст - прямое противоречие гипотезе "насыщения".

[Hale 1]

З.Ы. если хотите качественно аргументировать документами, есть такой стиль, указывать точные ссылки на материал, а не сыпать непонятными картинками вне контекста.

>во всяком случае у CST, использует AVX2 только на коротком подготовительном этапе расчета

AFAIK, HFSS давно использует AVX2 и AVX-512 в DrivenModal. Сложности HFSS всегда были как раз на генерации меша и препроцессинге, в которые упирается решение маленьких задач меньше 8Гб объемом.

[Freesom 15]

53 minutes ago, Hale said:

 

Еще раз об этом бреде насыщения. Упомянутое насыщение может происходить только в трех случаях 1) Если у вас медленная шина FSB между процессором и контроллером памяти 2)Если у вас пропускная кеша ниже пропускной контролера памяти 3)Если у вас пропускная конвейера самого процессора ниже пропускной памяти. А поскольку дефакто ответ на все три пункта - НЕТ-НЕТ-НЕТ, то любое "насыщение" может быть связано только с особенностями софта. Симуляторный софт во время решения по природе активным IO не занимается, а в частности активно использует SIMD инструкциии чтобы уменьшать оверхед.

1) FSB в процах не используется уже 12 лет, с момента как вышел Nehalem. Ещё бы FB-DIMM вспомнил

2) Пропускная способность кэша никак не поможет читать из памяти быстрее - если в кэше нет то чего надо прочитать (а когда расчётная матрица 100 ГБ в оперативке, по определению нужного в кэше размером 10 МБ не будет)

3) Каждое ядро может читать за такт определенное число строк из памяти умножить на разрядность памяти, поделить на латентность кэша. В итоге у интела каждое ядро может читать не быстрее 15-18 ГБ/сек. Не зависимо от особенностей софта и инструкций, размеров кэша и каналов памяти у контроллера. А вот FEM солвер крайне требователен к производительности памяти, так что тут ядра проца толкаясь локтями за доступ к памяти очень быстро выводят контроллер памяти в насыщение.  Я уже не говорю, что ещё в Broadwell процах с количеством ядер больше 10 интегрировано два контроллера памяти, так как одно кольцо больше 10 ядер не делают. Но не буду травмировать вашу и без того перегретую геймерскими i7 Extreme психику.

1 hour ago, Hale said:

1)"96Gb RAM per CPU", подразумевает multi-CPU. А этого надо избегать любой ценой. Автоматика в ОС рано или поздно закинет кусок данных на соседний нод NUMA и тогда получите падение производительности на 15% сходу. А на SP просто без разницы - берете столько памяти сколько вам надо под задачу.

Ну значит это был совет для CST, потому как CST в курсе NUMA и позволяет выбирать количество задействуемых процессоров, а не только расчётных потоков.

 

1 hour ago, Hale said:

2)"The fastest RAM", а вот Freesom не согласен. Freesom утверждает что память там насыщается, и нет смысла ее ускорять не используя больше 14 ядер. И чему верить? ну и остальной текст - прямое противоречие гипотезе "насыщения".

Ну во первых, Freesom так и написал: "Высокая частота памяти это всегда хорошо, тут прямая зависимость". Во вторых, для 6-канальных xeon да, нет смысла брать 24-ядерные версии, т.к. 14 ядер уже загонят в насыщение 6-канальный контроллер памяти. Именно это и имеет ввиду CST, когда рекомендует не выбирать более 16 ядер на Cascade Lake с 6 каналами (и соответственно упомянутые выше 10 ядер для проца с 4 каналами):

56 minutes ago, Hale said:

З.Ы. если хотите качественно аргументировать документами, есть такой стиль, указывать точные ссылки на материал, а не сыпать непонятными картинками вне контекста.

Стараюсь не делать этого для тех , кто назначает любой аргумент бредом сивый кобылы и строчит геймерские потоки подсознания, оторванные от расчётной реальности. Я давно хотел сделать для себя наглядную оценку влияния каналов памяти и количества задействованных ядер на расчетное время F-солвера. Когда в распоряжении более полутора десятка компов разных поколений, количества ядер у процов, NUMA-нутости и объема памяти вплоть до 256 ГБ, возникает выбор на какой кинуть очередную задачу. На основе опыта это решение принимается быстро, но вот построить графически эту зависимость как-то всё времени не хватает

[Hale 1]

>FSB в процах не используется уже 12 лет

Поэтому и ответ - нет там ботлнека.

>Пропускная способность кэша никак не поможет читать из памяти быстрее - если в кэше нет то чего надо прочитать

Именно поэтому ответ - память медленнее всего переисленного и процессор не может быть боттнеком, входящим в насыщение, если его не использовать почти эксклюзивно для порожней работы.

>у интела каждое ядро может читать не быстрее 15-18 ГБ/сек

откуда данные? насколько я знаю, кеш для того и придуман чтобы нивелировать задержку на выборку. Кроме того - переворот матриц производится простыми последовательными умножениями и перекладываниями(ну в зависимости от алгоритма, которых я с Вуза даже не открывал... но не суть) вполне последовательных данных. А насколько я себе представляю, современный кеш читает в память с небольшим упреждением как раз для исполнения последовательного кода и чтения последовательных данных. Кроме того DDR, да еще многоканальный читает огромными блоками, т.е. 64бит x2 x-число_каналов, возможно большими. Т.е. вы выбираете одно слово, а в кеш с вероятностью как минимум 50% попадает еще несколько последующих даже без упреждения. Только за счет многоканальности. А пропускная кеша - это 80L1/40L2/20L3 GB/s против 10GB/s пропускной памяти (D.Molka "Main Memory and Cache Performance of Intel Sandy Bridge and AMD Bulldozer") из того что я нашел на графиках тестирования. Цифры там для частного случая, но относительные масштабы примерно ясны. Берем ваши 18Gb и умножаем на x4 - это примерная пропускная L2.

Если смотреть графики, вот где есть насыщение, это в памяти, всегда. При любом тестировании. А расхождение линейного участка от количества каналов, это уже специфика тестирования по моему мнению. У кого-то угол и потолок возрастает от количества каналов, у кого-то насыщается.

 

про STREAM

https://www.intel.ru/content/dam/doc/white-paper/resources-xeon-7500-measuring-memory-bandwidth-paper.pdf

your STREAM bandwidth score would be ~25% below what the platform is actually transferring to/from memory.

To ensure the STREAM result reflects the actual bandwidth capabilities of the  platform, and the extra “read” transaction is not issued, most processors have a “non-cacheable” write transaction or something  similar,  which  tells  the  processor  to  do  the  write  without  first  doing  a  “read  for  ownership”.  

Но это фактически технологическое измерение к реальной жизни отношения не имеющее.

И где ссылка на документы которые вы скриншотите? вы говорите о STREAM, но у вас даже нет подтверждения что они использовали именно его, а не тестировали свой серверный совт своими бенчмарками.

 

>А вот FEM солвер крайне требователен к производительности памяти, так что тут ядра проца толкаясь локтями за доступ к памяти очень быстро выводят контроллер памяти в насыщение.

- Замечательно, вы мне только что доказывали что в насыщение входят ядра процессора и до 18 ядер не способны использовать 6-канальный контроллер на полную, значит 2-канального достаточно. Так было дело?

... вот что я вужу - вы путаетесь в собственоручно построенной реальности.

 

>Но не буду травмировать вашу

Ради бога, не проецируйте на меня свои душевные расстройтсва.

>Ну значит это был совет для CST, потому как CST в курсе NUMA и позволяет выбирать количество задействуемых процессоров, а не только расчётных потоков.

А какая разница? Один поток- один процессор. Умеет ли HFSS решать на какое ядро ему закрепитьк акой поток? Нет. В windows10 ядро ОС решает какое ядро быстрее(да, она знает о "предпочтительных" ядрах Интеля) и меньше загружено. Плохо что HFSS не может исключить из этого процесса HT копии... но по моему новый планировщик Windows лучше справляется с опознаванием нагрузки на ядрах чем win7. Дело же не в ядрах, а в данных, чтобы точно знать какой нод NUMA привязан к какому ядру и знать куда ты пишешь. Если честно, я даже AWE не освоил, и полагаю что это чертовски муторная задача, вдобавок исключающая кроссплатформенность. Я не думаю что они ее вообще решали, и скорее всего этим занимается ОС плевав на пенальти пересылки.

 

....Во вторых, для 6-канальных xeon да, нет смысла брать 24-ядерные версии, т.к. 14 ядер уже загонят в насыщение 6-канальный контроллер памяти.

Блин. вы точно развернулись на 180 градусов. Где тут противоречие с тем что я пишу? Или вы спорите просто для того чтобы спорить.

>Стараюсь не делать этого для тех , кто назначает любой аргумент бредом сивый кобылы

потмоу что без ссылок - это бред сивой кобылы. Т.к. противоречит элементарным принципам которым нас со второго курса учили.

[l1l1l1 0]

Уважаемые Freesom и Hale ! Пожалуйста прилагайте дополнительные усилия, чтобы в техническом споре не переходить на личности и не употреблять грубых выражений.

[Freesom 15]

 

8 hours ago, Hale said:

Замечательно, вы мне только что доказывали что в насыщение входят ядра процессора

Благо тут всё записано и я ни разу не написал такого. Насыщается только контроллер памяти. Насыщается чем? Ядрами процессора, которые конкурируют за доступ к памяти. Я не пойму, в чём у вас сложность с пониманием этой простой мысли? Проблема с языковой конструкцией или смысловой нагрузкой?

9 hours ago, Hale said:

>у интела каждое ядро может читать не быстрее 15-18 ГБ/сек

откуда данные?

Да хоть самостоятельно можно проверить, ограничив в биосе количество ядер до 1. Это если совсем скил в google-fu не наработан. Вот статья, откуда графика, там всё и так понятно, у других (и HP и Intel) будет то же самое

 

9 hours ago, Hale said:

А какая разница? Один поток- один процессор.

Разница существенная, если солверу указан один процессор на машине с двумя NUMA узлами и, например, 8 потоков (по числу ядер), то в диспетчере задач чётко видно, что солвер загружает только один процессор (причём почему-то считая с конца), на все его 8 ядер. А windows уже отвечает за то, чтобы этим потокам выделялась ближайшая к ним память. Может для HFSS это дичь, но судя по описанию проблем с распараллеливанием даже на 4 ядра в HFSS, у них всё грустно с программистами.

[K0nstantin 4]

Какие-то разговоры о высшей материи...))
Автору: похожая загруженность по процессору. Тоже с виду все 6 ядер крутятся, настойки не менял, всегда стоят 6 ядер и 1 задача. Но поэкспериментировать любопытно.

Вопрос. В какое расширение можно экспортировать модель, чтобы она не сохраняла Субблоки модели? Экспортировал в STEP, ASIC SAB. При импорте в PTC Creo в виде Сборки видны все составляющие модели. У меня их много. Хочу чтобы сохранились только Блоки ВЕРХНЕГО уровня (планирую их экспортировать по очереди как детали) и сделать сборку. Пробовал в Creo импортировать в виде деталей, потом экспортировать в STEP. При импорте Субблоки снова видны (

 

 

[Hale 1]

неумение формулировать и нежелание давать точные ссылки вместе с безумным желанием поспорить у некоторых соучастников приводит вот к таким вот результатам:

Поясняю, картинка без ссылки ЯВНО и без вариантов говорит о насыщении (боттлнеке) ядер. Т.е. прямая линия от 0(!) до 8 ядер вообще не расходится и не влияет на пропускную. О чем это говорит? О том что память ни при чем и процессор вошел в насыщение порожним кодом. Дальнейшее распараллеливание входящих данных помогает и линии расходятся. Впрочем быстро упираясь в пропускную памяти. И вот в этом случае опять таки помогает увеличение количества каналов (потолок поднимается).
Это какая-то безумная картинка не имеющая к симуляторам никакого отношения. Но типичная для всяких веб и гейм серверов занимающимся большим I/O с сетью и внутренним обдумыванием "чоделать".

 

Ну а в сухом остатке старая формула остается без изменений - максимальная пропускная для переклвдывания памяти и максимальные клоки ядер при их небольшом количестве (от 2 до 8).

[Freesom 15]

4 hours ago, Hale said:

Это какая-то безумная картинка не имеющая к симуляторам никакого отношения.

Дело в том, что эта картинка - типичный тест для задачи с упором на пропускную способность памяти, коим симуляторный FEM и является. В отличие от MOM, у FEM прореженные матрицы, поэтому для процессора это не шибко интенсивная задача, а вот для контроллера памяти - максимальная из-за размеров матриц. Впрочем, те кто понимает о чём речь и так знают на что обращать внимание и как это тестируется:

 

Spoiler

А про "веб и гейм серверы" - это, конечно, снова мимо, там многоядерные варианты с 28 ядрами прекрасно себя проявляют, это как раз тот случай, где флопсы и большой кэш важнее всего.