Hale 1 19 июля, 2021 Опубликовано 19 июля, 2021 · Жалоба 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 19 июля, 2021 Опубликовано 19 июля, 2021 · Жалоба З,Ы. Про параметрические свипы. В версиях 2020 и 2021R1 наложены безумные ограничения на параметрику. Для задействования 2 параметрических задач в параллеле (свипы) вам потребуется АЖ 16(!) HPC лицензий. Обещали вдвое уменьшить требования на параметрику в версии 2021R2, видимо народ их засыпал кирпичами. >Есть специализированные машины, именно для продуктов ANSYS, не только для HFSS маркетинговое фуфло в основном для университетов и постеров, сколько мы смогли залупить ядер в кластер бульдозеров. То что я видел - решения менее оптимальные чем офисный i5; преимущество обычно только в блейд-сборке под ключ. Короче, для ленивых. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Freesom 21 19 июля, 2021 Опубликовано 19 июля, 2021 · Жалоба 41 minutes ago, Hale said: >. У интела для того чтобы насытить 4-х канальный контроллер памяти бред сивой кобылы. скорее всего основан на тестах производительности в играх. Векторные операции последних лет вообще могут сосать память как пылесос. Не-а, он основан на гайдах HP по использованию пролиантов. Но, не спорю, это конечно тяжко для понимания тем, кто кроме игр особо ничего не видел. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Hale 1 20 июля, 2021 Опубликовано 20 июля, 2021 · Жалоба И что же вы запускаете на серверах пролиант? Веб, или геймсервер? Кончайте этот бред, честное слово. Это задаче-ориентированные тесты и никто на серверной платформе не гоняет ни многопоточный BLAS ни тем более чисто-матричные задачи, которые в конечном итоге сводятся к последовательному перекладыванию локальных данных. Память - это не port-io, с ondie контроллерами нет боттлнека процессора. Ботлнек появляется на NUMA, и тем более при на FSB процессорах. А на SP Xeon, чем меньше ядер - тем дальше боттлнек. При грамотном программировании все читается с той скоростью с которой контроллер может высосать из модулей, с потолком примерно на пропускной кеша. А вот вопрос в пригодности программирования разнообразных серверов и I/o-ориентированного софта, это другое дело. Процессор может выполнять столько порожней работы, что простои и насыщение там не за горами. кстати, простой эксперимент. запускаем testmem5 на 4-канальной машине в 2,4,6,8 потоков. Сами тесты поддерживают оптимизацию до 2 каналов, но это только оптимизация тестирования. Загрузку по каналам распеределяет не тест а операционка с процессором по количеству потоков. Видим что никакого насыщения нет, в Lines и тетрис можно продолжать играть без тормозов, можно даже blas тестирование с короткими задачами запускать. А вот веб браузер будет ожидаемо тупить с подгрузкой картинок. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Pubzor 0 20 июля, 2021 Опубликовано 20 июля, 2021 · Жалоба Спасибо всем. Буду ориентироваться на советы. Речь про фермы не шла. Нужен лишь ПК по мощнее, а в ступор загнали непонятки с памятью. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Freesom 21 20 июля, 2021 Опубликовано 20 июля, 2021 · Жалоба 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 20 июля, 2021 Опубликовано 20 июля, 2021 · Жалоба >а софтовые потоки это ни о чём воблин. Дожили. И софтовый решатель 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 20 июля, 2021 Опубликовано 20 июля, 2021 · Жалоба З.Ы. если хотите качественно аргументировать документами, есть такой стиль, указывать точные ссылки на материал, а не сыпать непонятными картинками вне контекста. >во всяком случае у CST, использует AVX2 только на коротком подготовительном этапе расчета AFAIK, HFSS давно использует AVX2 и AVX-512 в DrivenModal. Сложности HFSS всегда были как раз на генерации меша и препроцессинге, в которые упирается решение маленьких задач меньше 8Гб объемом. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Freesom 21 20 июля, 2021 Опубликовано 20 июля, 2021 · Жалоба 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 21 июля, 2021 Опубликовано 21 июля, 2021 · Жалоба >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 21 июля, 2021 Опубликовано 21 июля, 2021 · Жалоба Уважаемые Freesom и Hale ! Пожалуйста прилагайте дополнительные усилия, чтобы в техническом споре не переходить на личности и не употреблять грубых выражений. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Freesom 21 21 июля, 2021 Опубликовано 21 июля, 2021 · Жалоба 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 5 22 июля, 2021 Опубликовано 22 июля, 2021 · Жалоба Какие-то разговоры о высшей материи...)) Автору: похожая загруженность по процессору. Тоже с виду все 6 ядер крутятся, настойки не менял, всегда стоят 6 ядер и 1 задача. Но поэкспериментировать любопытно. Вопрос. В какое расширение можно экспортировать модель, чтобы она не сохраняла Субблоки модели? Экспортировал в STEP, ASIC SAB. При импорте в PTC Creo в виде Сборки видны все составляющие модели. У меня их много. Хочу чтобы сохранились только Блоки ВЕРХНЕГО уровня (планирую их экспортировать по очереди как детали) и сделать сборку. Пробовал в Creo импортировать в виде деталей, потом экспортировать в STEP. При импорте Субблоки снова видны ( Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Hale 1 2 августа, 2021 Опубликовано 2 августа, 2021 · Жалоба неумение формулировать и нежелание давать точные ссылки вместе с безумным желанием поспорить у некоторых соучастников приводит вот к таким вот результатам: Поясняю, картинка без ссылки ЯВНО и без вариантов говорит о насыщении (боттлнеке) ядер. Т.е. прямая линия от 0(!) до 8 ядер вообще не расходится и не влияет на пропускную. О чем это говорит? О том что память ни при чем и процессор вошел в насыщение порожним кодом. Дальнейшее распараллеливание входящих данных помогает и линии расходятся. Впрочем быстро упираясь в пропускную памяти. И вот в этом случае опять таки помогает увеличение количества каналов (потолок поднимается). Это какая-то безумная картинка не имеющая к симуляторам никакого отношения. Но типичная для всяких веб и гейм серверов занимающимся большим I/O с сетью и внутренним обдумыванием "чоделать". Ну а в сухом остатке старая формула остается без изменений - максимальная пропускная для переклвдывания памяти и максимальные клоки ядер при их небольшом количестве (от 2 до 8). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Freesom 21 2 августа, 2021 Опубликовано 2 августа, 2021 · Жалоба 4 hours ago, Hale said: Это какая-то безумная картинка не имеющая к симуляторам никакого отношения. Дело в том, что эта картинка - типичный тест для задачи с упором на пропускную способность памяти, коим симуляторный FEM и является. В отличие от MOM, у FEM прореженные матрицы, поэтому для процессора это не шибко интенсивная задача, а вот для контроллера памяти - максимальная из-за размеров матриц. Впрочем, те кто понимает о чём речь и так знают на что обращать внимание и как это тестируется: Spoiler А про "веб и гейм серверы" - это, конечно, снова мимо, там многоядерные варианты с 28 ядрами прекрасно себя проявляют, это как раз тот случай, где флопсы и большой кэш важнее всего. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться