А ваш CAE будет работать на новом процессоре?

[Bonusfrag 104]

несжимаемой среды - воздуха.

 

paste and copy secret

[HFL 34]

Выяснил с огорчением, что мое ЦУ не было отработано и по 10000 на каждое ядро задачу не посмотрели.

 

 

Я правильно понял что при < 10 000 ячеек на ядро это предел масштабируемости вашего кода ?

[Bonusfrag 104]

 

Выяснил с огорчением, что мое ЦУ не было отработано и по 10000 на каждое ядро задачу не посмотрели.

 

 

Я правильно понял что при < 10 000 ячеек на ядро это предел масштабируемости вашего кода ?

 

FV не любит, когда на ядро приходится мало ячеек. Рекомендация из мануала - от 50000 на ядро.

менее 10000 на ядро брать точно не надо - в большинстве случаев будет только хуже. 

 

вот моя картинка - брал тестовую задачу про сопло.

при 12 потоках по нагрузке на ЦП видно было, что он недогружен вычислениями - в этом случае было 17500 ячеек на ядро.

[a_schelyaev 366]

 

Выяснил с огорчением, что мое ЦУ не было отработано и по 10000 на каждое ядро задачу не посмотрели.

 

 

Я правильно понял что при < 10 000 ячеек на ядро это предел масштабируемости вашего кода ?

 

На физическое ядро!

Может быть и 8000 тысяч. Детально этот вопрос не исследовали с точностью до каждой вишенки, поэтому просто родили критерий, что ниже 10000 на ядро не опускаться. Т.е. примерно в этом районе. Я разработчиков попросил, чтобы до 1000 опустились, но мне лишь обещали подумать, но не более того.

Почему у Александра на 10000 (на физическое ядро?) наблюдается замедление - нужно смотреть.

 

А это плохо вообще или как? У вас какие характеристики решалки с этой точки зрения?

 

Собственно я и планировал провести более подробное исследование, т.к., например, если включать HT, то это дает до 20% прибавки в скорострельности. Т.е. код потихоньку вылизывается. Однако из-за энтузиазизма отдельных личностей в мое отсутствие работу можно выкинуть в корзину.

 

добавил оценку стоимости единицы производительности для двух процессоров;

Спасибо за учет пожеланий трудящихся) Еще бы описание к этому графику и цифры не в относительной шкале.

 

И еще вопрос: 5 стр, 3 абзац.

Истечение из сопла и тут же движение несжимаемой среды - воздуха.

 

 

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

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

:) 

[HFL 34]

А это плохо вообще или как? У вас какие характеристики решалки с этой точки зрения?

 

 

Это странно. У меня масштабирование прекращается при <1500 ячейках на одно ядро. Оптимум где то в районе ~5000 за счет кеш-эффектов, когда большая (не вся, а вероятно наиболее используемая) часть данных влезает в кеш процессора. Если делать больше то там никаких нелинейных эффектов не наблюдается, разве что скорость самой памяти начинает играть бОльшую роль. Это  для чисто CPU версии. Для GPU там своя зависимость. GPU я особо не копал (максимум что пробовал это 2xK20m) а вот по CPU прошелся весьма подробно до ~600 ядер (и по strong scale и по weak scale)

 

PS: эффективность включения HT кстати дала странные результаты. Например на E5-26xx HT однозначно ухудшает производительность, на  i7-4700HQ либо не влияет либо слегка ухудшает а вот на Атоме однозначно улучшает (но не в разы а % на 40). Как я понял это зависит от количества управляющего (он в основном целочисленный) и собственно счетного (с плавающей точкой) кода в одном счетном цикле.

 

Оценку влияния интерконнекта  особо не делал. Он у меня весь Infiniband (от SDR до FDR на разных доступных кластерах)

 

PS: Более показателен график не ускорения от числа ядер а эффективности от числа ядер где эффективность - отношение реального ускорения к идеальному.

[a_schelyaev 366]

А у вас сетка структурированная?

 

 

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

[HFL 34]

Да - сетка структурированная

[HFL 34]

на малом количестве ядер

 

А малое это сколько ? Я просто на графиках заметил одну типичную вещь 

Прекращение масштабирования при использовании > 20 ядер (если я правильно понял надпись под картинкой)

Это очень напоминает использование блокирующего обмена данными в MPI. Там суть в том что сам счет в поддоменах

параллелен а вот обмены по сути идут в один поток  ну или точнее в "цепочку". Это не так страшно когда обменов "мало" а счета "много" (отсюда такое требование к числу ячеек на ядро) но убивает показатель strong scaling. 

 

Вот пример сравнения использования блокирующих и неблокирующих обменов на strong scaling - тесте

 

 

 

 

 

[a_schelyaev 366]

Да - сетка структурированная

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

 

на малом количестве ядер

 

 

 

А малое это сколько ? Я просто на графиках заметил одну типичную вещь  

 

В пределах четверки.

[HFL 34]

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

 

 

Ну это как раз понятно.  Это накладные расходы которые как раз хорошо параллелятся с HT что собственно и объясняет его эффективность на вашем коде.

 

PS: Локальная адаптация (разбиение ячейки на более мелкие в рантайме) и подвижные границы это чай не бином Ньютона 

 

Все этим баловались   

(кликабельно)

[a_schelyaev 366]

C сеткой как работали?

1. Через булевы операции, обрезая ячейки;

2. Морфинг гекса сетки?

3. Immersed body?, 

[HFL 34]

1+3

 

 

PS: Этой анимашке лет 10. 

[a_schelyaev 366]

Да, кстати, если данные кому по воркбенчу нужны по соплу, то в личку свистите.

1+3

Только двухмерный случай или произвольный трехмерный?

[HFL 34]

Только двухмерный случай или произвольный трехмерный?

 

 

Конкретно этот код был в 2D (в те времена 3D было делать тяжеловато в плане временнЫх затрат да и вобщем не нужно для данной конкретной разовой задачи).

Сейчас есть версия для 3D для расчета абляции но там чуть иной алгоритм и совершенно другой код (нельзя считать движение тела без переделки кода) 

 

А так любой каприз за ваши деньги ©  

[a_schelyaev 366]

Ой ну это это вряд ли. Это уже скорее про нас - уже в два сторонних продукта решалку продали в исходниках.

Хотя по абляции у нас запланирована работа на следующий год.

[HFL 34]

Ой ну это это вряд ли. Это уже скорее про нас - уже в два сторонних продукта решалку продали в исходниках.

Одних знаю, а вторые кто ? Секрет ? 

Хотя по абляции у нас запланирована работа на следующий год.

 

 

Ага, читал заявку от минобра под вас 

 

PS: Считать  дисперсную к-фазу эйлером это моветон 

[a_schelyaev 366]

Первые CFDesign, которые потом как-то переоформились в Autodesk CFD Simulation и с тех пор следы теряются.

Вторые - Саров.

[a_schelyaev 366]

 

PS: Считать  дисперсную к-фазу эйлером это моветон 

 

Чем предложите? Лагранжевыми частицами? Проходили уже.

[HFL 34]

 

 

PS: Считать  дисперсную к-фазу эйлером это моветон 

 

Чем предложите? Лагранжевыми частицами? Проходили уже.

 

Горение полифракции за стабилизатором в зоне обратных токов Эйлером точно не посчитать. Не говоря уже об отскоке/ высаждении на стенку.

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

 

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

Вы что то не так делаете 

 

CFDesign, которые потом как-то переоформились в Autodesk CFD Simulation

 

Про этих не знал.  

[a_schelyaev 366]

Не заметил в начале - так у вас явный решатель. Тады понятно.

 

Касаемо абляции - пусть ученые наши думают.

:)