Суперкомпьютер своими руками для расчетов в ansys и 3d приложениях

[a_schelyaev 366]

Sandy Bridge, 6 cores, Elapsed Time in seconds ~ 30000.

Что-то долго все это для статики.

Такое впечатление, что там еще и контакт есть, если так долго считает на такой тачке с таким объемом памяти.

у них там еще указано - Nonlinear Static (6 Steps)

т.е. это 6 проходов? или как это понимать?

т.е. как минимум надо 2.5*6, не?

Про 77 уточню у Джораева.

Steps это шаги нагружения, судя по всему. По нашему, CFD-бразильскому, аналог итераций.

А хотя нет - шаг нагрузки это инкрименты.

[Гость ISPA]

т.е. как минимум надо 2.5*6, не?

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

И ускоряют они 2 процессора сразу двумя ускорителями.

Чтобы ускорение было побольше.

[a_schelyaev 366]

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

А какой тип анализа используется?

т.е. это 6 проходов? или как это понимать?

Выяснил.

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

[Bonusfrag 104]

Steps это шаги нагружения, судя по всему. По нашему, CFD-бразильскому, аналог итераций.

А хотя нет - шаг нагрузки это инкрименты.

а что такое Nonlinear Static (1 step; 39 increments) - которое жирным выделено?

в общем, интересно, как понимать тут steps и increments

Про 77 уточню у Джораева.

это как раз понятно на 100% - заметь, он использует TFLOPs - т.е. в конце стоит множ.число. Т.е. это именно FLoating point OPeration, а не FLOPS.

[a_schelyaev 366]

в общем, интересно, как понимать тут steps и increments

Степ - случай нагружения. Например, первым степом дал нагружение статическое. А во втором степе ударил молотком.

Инкремент - шаг приращения нагрузки, внутри степа. Он итерирует по своему - нагрузку увеличивает и смотрит сходимость на каждом шаге приращения.

Если задача нелинейная, то количество инкрементов может существенно вырасти.

Немного покопался на сайте NVIDIA и нашел одну содержательную презенташку по батьке-Abaqus.

S0431-GTC2012-Evolving-GPU-Dassault.pdf

Цельнотянутая <noindex>отсюда</noindex>.

[Bonusfrag 104]

просто сравнил два примера из этой презентации - странно смотрится:

сравнивал, где 1 step и 8 ядер:

26 TFLOPs, 4,27 млн уравнений, 39 increments, 80000 сек

100+ TFLOPs, 3,07 млн уравнений, 5 increments, 11000 сек

если не сравнивать первую пару чисел, то вроде всё ок: сделали в 8 раз больше шагов, получили в 8 раз больше время.

Но вот эти TFLOPs тут портят всю картину, и появляется сомнение - правильно ли ISPA предложил пересчет...

Или в презентации косяк....

?

[a_schelyaev 366]

Пока не поймем что за тип анализа, можно долго гадать. Вполне возможно, что задача с контактом.

[Гость ISPA]

Но вот эти TFLOPs тут портят всю картину, и появляется сомнение -

правильно ли ISPA предложил пересчет...

Или в презентации косяк....

?

Все правильно мы понимаем и считаем. Я про это с самого начала говорю. Надо эффективно использовать процессор.

Но только эти два ускорителя стоят не меньше 360 000 рублей.

А у меня процессор стоит 15 000 рублей.

И ИСПА считает быстрее.

[Bonusfrag 104]

И ИСПА считает быстрее.

т.е. вас не смущает, что 100+ TFLOPs выполняются за 11000 сек, а 26 TFLOPs - за 80000 сек, т.е. один вариант в 28 раз быстрее другого....?

[Гость ISPA]

т.е. вас не смущает

Меня не смущает, что ИСПА на ЦПУ быстрее чем Абакус.

Я сразу сказал, что ИСПА не получается ускорить с помощью Квадро.

Вы только не забывайте, что в статье ДВА ускорителя и у каждого 2700 ядер.

Я вам сразу сказал, что новая версия ИСПА считает очень быстро.

А вы не верили.

[Bonusfrag 104]

А вы не верили.

Я? цитату, пожалуйста.

[Гость ISPA]

Я? цитату, пожалуйста.

Я не лично Вас имел в виду. Вы то как раз хотите разобраться в этом вопросе и докопаться до истины.

А любая нелинейная задача - это последовательное решение линейных задач.

Поэтому производительность и компьютеров и супер компьютеров измеряют Линпаком.

Линейной решалкой.

[Fedor 1 597]

Правильно. Здесь не кафедральная мурзилка, чтоб голову морочить новизной с актуальностью

[Гость ISPA]

Вот немного информации по ускорителю из статьи по Аьакусу.

Флагман Tesla K20X с 2688 ядрами CUDA, как заявлено, обеспечивает самый высокий из возможных ныне уровень производительности для одного GPU, а именно 3,95 терафлопс в вычислениях с одинарной точностью и 1,31 терафлопс в вычислениях с двойной точностью. На его борту присутствует 6144 Мбайт памяти GDDR5 с 384-битным интерфейсом. Частота ядра/памяти равна 732/5200 МГц. Максимальная потребляемая мощность достигает 235 Вт.

А скорость 1,31 терафлопс в вычислениях с двойной точностью - хороший рекламный ход.

И задача в 70 Тфл рашалась бы за 70 сек.

[HFL 34]

Сетка распределяется в виде декомпозированной матрицы - куски матрицы.

[url="http://www.tesis.com.ru/infocenter/downloads/flowvision/fv_es09_tes2.pdf"]

Статья оставляет больше вопросов чем ответов.

Вопрос первый

Так как всё-таки происходит декомпозиция в вашем коде ?

1) Чисто геометрическая 2-х уровневая декомпозиция по расчётной области (domain decomposition)

Первый уровень (более крупный) - MPI, второй более мелкий - TBB

2) Гибридная декомпозиция - первый уровень - геометрическая декомпозиция ( с помощьюMPI) второй уровень - декомпозиция по физическим процессам (c помощью TBB)

Если вариант N1 то балансировка происходит только на втором уровне или на обоих ?

Вопрос второй

Передел масштабирования задачи с фиксированным числом узлов (strong scale limit) какой ?

Если по простому то каково предельное число ядер на задачу или предельное отношение числа узлов расчётной сетки / ядро процессора после которого задача не масштабируется?

Вопрос третий

Где сравнение результатов с балансировкой и без ?

PS: 64 процессора (или ядра ?) это ни о чём. Тест нужно делать на числе от сотен до тысяч ядер

[Vova 419]

просто сравнил два примера из этой презентации - странно смотрится:

сравнивал, где 1 step и 8 ядер:

26 TFLOPs, 4,27 млн уравнений, 39 increments, 80000 сек

100+ TFLOPs, 3,07 млн уравнений, 5 increments, 11000 сек

если не сравнивать первую пару чисел, то вроде всё ок: сделали в 8 раз больше шагов, получили в 8 раз больше время.

Но вот эти TFLOPs тут портят всю картину, и появляется сомнение - правильно ли ISPA предложил пересчет...

Или в презентации косяк....

?

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

Кроме того в расчете с контактом кроме STEP и INCREMENT есть еще ITERATION. В одном INCREMENTе может быть до 18 ITERATION.

Так что тут сравнивать скорость с линейной задачей не корректно будет.

Например эту задачу ИСПА и за месяц не решит(если решит, то я исправлю) :

<noindex>http://fsapr2000.ru/index.php?act=Attach&a...st&id=44171</noindex>

вот выписка из *.sta файла этой задачи, где первый Step посчитался легко и второй, который плохо сходился.

SUMMARY OF JOB INFORMATION:

STEP INC ATT ITER TOTAL STEP

1 1 1 4 0.0500 0.0500

1 2 1 1 0.100 0.100

.....................................

1 18 1 1 0.900 0.900

1 19 1 1 0.950 0.950

1 20 1 1 1.00 1.00

2 1 1 10 1.01 0.0100

2 2 1 10 1.02 0.0200

2 3 1U 4 1.02 0.0200

2 3 2 5 1.02 0.0225

2 4 1U 6 1.02 0.0225

2 4 2 3 1.02 0.0231

....................................

2 754 1 3 1.96 0.963

2 755 1 3 1.97 0.966

2 756 1 11 1.97 0.970

2 757 1 5 1.97 0.974

2 758 1 11 1.98 0.979

2 759 1 3 1.98 0.980

2 760 1 5 1.98 0.984

2 761 1 10 1.99 0.989

2 762 1 3 1.99 0.990

2 763 1 5 1.99 0.994

2 764 1 6 2.00 0.999

2 765 1 3 2.00 1.00

THE ANALYSIS HAS COMPLETED SUCCESSFULLY

[a_schelyaev 366]

2 HFL

Пункты мои:

1. Динамической балансировки для MPI режима нет. Пока.

2. Для многонитевого режима динамическая балансировка есть.

3. Декомпозиция работает не только для 2 в степени N, но и для любого количества процессоров. Хоть три. :)

4. Предела масштабирования два:

4.1 Нижний: упирается в превалирование доли обменов над долей вычислений и находится в районе 40-50 т.ячеек. Ниже этого уровня ускорение может пропадать.

4.2 Верхний: упирается в пропускную способность канала ЦП-память и зависит от конкретной железки. Ограничение чисто психологиечское, т.к. просто растет доля вычислений на узле.

5. Декомпозиция двухуровневая MPI+TBB. Оба уровня геометрические. Область бьется на домены. Количество доменов делается больше, чем количество расчетных ядер/узлов. Из этих доменов набирается область, которая уже и скармливается расчетному узлу. Балансировка происходит за счет перекидывания доменов из одной области в другую.

6. Сравнения "балансировка/без балансировки" под рукой нет. Материал рабочий у разработчика на компе и просить его сейчас оформить в удобочитаемом виде невозможно. Но сразу скажу, что отличия значительные. Поэтому основной рабочий режим запуска рекомендуется с максимальным задействованием всех ядер процессора в многоядерном режиме.

7. Статья старая, а работа, в ней описываемая, еще более старая. Если вам интересно, то на нашей решалке лично мы отлаживались в режиме в тысячи процессоров, а наши клиенты в 10000 процессоров.

Подчеркну - процессоров. Нареканий не было.

8. Недавно опытным путем установили, что теперь HT не тормозит расчет на 10%, а ускоряет его на 20%. Думаю теперь над новой системой лицензирования, чтобы не по ядрам продавать параллельные опции, а по процессорам или по узлам.

;)

[Bonusfrag 104]

8. Недавно опытным путем установили, что теперь HT не тормозит расчет на 10%, а ускоряет его на 20%. Думаю теперь над новой системой лицензирования, чтобы не по ядрам продавать параллельные опции, а по процессорам или по узлам.

У SQL неплохо сделан этот момент:

<noindex>http://download.microsoft.com/documents/ru...ce_Guide_RU.pdf</noindex>

Лицензии продаются парами, но минимум - можно купить на 4 ядра (см.ниже)

Одноядерные и двухъядерные процессоры отправлены в топку за счет повышающих коэффициентов.

учтена производительность AMD - для них добавлен понижающий коэффициент. Хотя как-то странно - получается на 6 ядер надо 4,5 лицензии, т.е. всё равно надо 6 лицензий. А вот на 12 ядер надо 9 (точнее - 10).

Т.е. наличие-отсутствие HT не влияет на лицензию.

Но не знаю - как сейчас - а SQL 2005 не имел никакой проверки количества задействованных ядер или ЦП

Т.е. имея лицензию на 1 ЦП (тогда они лицензировались на ЦП) можно было в настройках свободно включать все процессоры, какие есть. Не было никаких спец.ключей или проверок.

Странный момент - он меня тогда очень удивил.

Вам такой вариант не пойдет. Необходимо встраивать что-то типа CPU_ID, чтоб он (солвер) сообщал серверу лицензий - на чем запускается счет.

[Гость ISPA]

Правильно. Здесь не кафедральная мурзилка, чтоб голову морочить новизной с актуальностью

Кафедральная мурзилка продолжается.

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

Это действительно новизна. Для нелинейной задачи одна скорость, а для линейной другая. Какую наукообразную базу подвели.

И скорость Абакуса для линейной задачи тщательно скрывают.

Значит есть, что скрывать. Значит ИСПА быстрее.

[Vova 419]

Кафедральная мурзилка продолжается.

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

Это действительно новизна. Для нелинейной задачи одна скорость, а для линейной другая. Какую наукообразную базу подвели.

И скорость Абакуса для линейной задачи тщательно скрывают.

Значит есть, что скрывать. Значит ИСПА быстрее.

Так поэтому я и написал, что не ясно количество iteration. Если знать количество iteration то и можно посчитать скорость, которую можно сравнить.

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

Или вы заказ на сравнительные расчеты делали, а его не выполнили?