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

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


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



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

 

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

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

 

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

 

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

 

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

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

 

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

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

post-26004-0-99731100-1414947571.png

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

 

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

 

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

 

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

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

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

 

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

 

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

 

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

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

 

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

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

 

 

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

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

:) 

Ссылка на сообщение
Поделиться на других сайтах
А это плохо вообще или как? У вас какие характеристики решалки с этой точки зрения?

 

 

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

 

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

 

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

 

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

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

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

 

 

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

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

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

 

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

post-34943-0-87556100-1415196995_thumb.png
Прекращение масштабирования при использовании > 20 ядер (если я правильно понял надпись под картинкой)
Это очень напоминает использование блокирующего обмена данными в MPI. Там суть в том что сам счет в поддоменах
параллелен а вот обмены по сути идут в один поток  ну или точнее в "цепочку". Это не так страшно когда обменов "мало" а счета "много" (отсюда такое требование к числу ячеек на ядро) но убивает показатель strong scaling. 
 
Вот пример сравнения использования блокирующих и неблокирующих обменов на strong scaling - тесте
post-34943-0-29750300-1415198079.png

 

 
 
 

 

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

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

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

 

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

 

 

 

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

 

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

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

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

 

 

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

 

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

 

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

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

post-34943-0-62382800-1415199354_thumb.gif

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

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

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

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

3. Immersed body?, 

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

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


1+3

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

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

 

 

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

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

 

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

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

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

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

:rolleyes:

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

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

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

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

 

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

 

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

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

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

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

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

 

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

 

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

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

 

 

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

 

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

 

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

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

 

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

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

 

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

 

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

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

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

 

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

:)

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

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

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

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

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

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

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

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

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

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

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




×
×
  • Создать...