Приостановка расчета

[sergeyd 3]

2 ИСПА

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

уточните источник, пжлста ваших познаний ансис.

2 Esdur

работаем со всем софтом (есть легалки и ансис и настран и абакус), есть свои наработки.

можно устроить бенчмарк.

скажем для большой задачи (10-40 млн неизвестных) порешаем +

сохраняю матрицу в нейтральном формате

(например, HarwellBoeing). возьметесь порешать?

не вполне понял, какие у вас успехи с матрицами МКЭ (симм положит.определенными)?

[EsDur 0]

2 Esdur

работаем со всем софтом (есть легалки и ансис и настран и абакус), есть свои наработки.

можно устроить бенчмарк.

скажем для большой задачи (10-40 млн неизвестных) порешаем +

сохраняю матрицу в нейтральном формате

(например, HarwellBoeing). возьметесь порешать?

не вполне понял, какие у вас успехи с матрицами МКЭ (симм положит.определенными)?

У нас хорошие успехи с матрицами МКЭ, недавно сравнивались на тяжелых задачах. С большой задачей и с бенчмарком есть только одна проблема - чрезвычайно плотный график работы по проектам. Я не очень понял как вы в HarwellBoeing собираетесь решать матрицу например 40 млн.? Тут больше подойдет какой-нибудь бинарный распределенный формат. И на каком компе? На Ломоносове? А как передать данные, это куча гигабайт. И что будет если успешно решим? Академический интерес тоже есть конечно, но на него времени особо не хватает, к несчастью. Нас через несколько месяцев ждут бенчмарки уже по 500 млн. неизвестных на очень тяжелых задачах из МКЭ.

[sergeyd 3]

ансис решали до 40 млн неизвестных на слабом кластере.

задача практическая.

решим настран, абакус сами

(если не справимся, позовем А.Щеляева)

я HB предложил просто как вариант передачи матриц. ()

если вам интересно сравнить с импортным софтом

сколько-нибудь всерьез (в руках даже не разработчиков, а опытных пользователей)

то велкам.

это нужно делать ровно на тех же матрицах.

будете ОБОСНОВАННО доказывать превосходство над ансис.

хотя бы в одной задаче.

сообщите, в каком виде готовы загружать матрицы со стороны.

(хотя признаться линейные задачи лично меня уже мало интересуют

ансис и тп занимаются ради нелина)

[Гость ISPA]

2 ИСПА

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

уточните источник, пжлста ваших познаний ансис.

Источник, как говорится, самый надежный. Одинаковая сетка решается в ANSYS и в ИСПА. Плохо обусловленные задачи в ANSYS не сходятся, а в ИСПА сходятся. При решении в ИСПА сойдется любая плохо обусловленная сетка. Именно по этой причине в ИСПА используются видео ускорители. И при этом не нужно гнаться за размерностью. Обусловленность связана не только с размерностью. Надо просто делать умные тесты и на них сравнивать программы, а не повторять из топика в топик, что ANSYS лучшая в мире программа и виноваты пользователи если решение не сходится за конечное число итераций. Прочитайте еще раз что вы написали в параллельной ветке. Это уже просто смешно, когда вы всех учите правильно читать хелп. Кстати, в теории к ANSYS ничего не описано. Ни по элементам, ни по алгоритмам. Все скрыто для кадром для разбирающего в этой области пользователя.

[a_schelyaev 366]

это нужно делать ровно на тех же матрицах.

будете ОБОСНОВАННО доказывать превосходство над ансис.

хотя бы в одной задаче.

Сергей, МКЭ для нас (разработчиков FlowVision) не является основной областью деятельности. Мы выполняем работу по проекту для другой организации, которой нужна наша линейная алгебра, чтобы МКЭ задачи решать. Они платят деньги и они покупают наше время и они предоставляют тесты, которые им нужны. Ибо это заказчик и именно он будет доказывать, если им это нужно, что они круче Ансиса.

Тратить время на фалометрию, если она не приносит денег, смысла для нас, как для частной компании, нет.

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

:)

Вот, допустим, если поймем мы, что у ISPA есть ноу-хау по эффективной передаче большого массива данных в GPU, которого даже у nVidia нет, то это интересно и на это можно тратить время.

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

[Гость ISPA]

Вот, допустим, если поймем мы, что у ISPA есть ноу-хау по эффективной передаче большого массива данных в GPU, которого даже у nVidia нет, то это интересно и на это можно тратить время.

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

Александр ты как всегда ничего не понял. Не обижайся только. Этот тест входит в SDK CUDA от NVIDIA. Я просто в нем разобрался и применил на практике в ИСПА. В CUDA можно параллельно передавать данные и считать, т.е. часть вектора считается, а часть передается. Передачу данных можно и нужно прятать под расчет. Ты только не обижайся. Каждый должен заниматься своим делом.

[a_schelyaev 366]

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

[Islander 2]

М-да... Например, есть "условная" задача, которая в КЭ пакете намба 1 решается 2-10 минут, а в пакете намба 2, допустим часов 6-8. Означает-ли это, что тот, кто первый радостно отрапортовал начальству "-Я посчитал!" заслуживает лишний пирожок на полке?:)

Но все равно, товарищи разработчики, вы все правильно пишите и двигаетесь в нужном направлении! За это отдельное спасибо.

[Гость ISPA]

М-да... Например, есть "условная" задача, которая в КЭ пакете намба 1 решается 2-10 минут, а в пакете намба 2, допустим часов 6-8. Означает-ли это, что тот, кто первый радостно отрапортовал начальству "-Я посчитал!" заслуживает лишний пирожок на полке?:)

Речь о другом. В реальных проектах очень часто нужно проводить сотни расчетов. И если один расчет идет 6-8 часов, то вы не успеете провести нужное количество расчетов. Вносите изменение и ждете результаты ночь. Это довольно тяжелый режим работы.

[Fedor 1 597]

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

" получали разницу первых относительно последних лишь в два раза" - проще процессор помощнее купить и не заморачиваться уникалкой. Или засунуть в тазик с касторкой и разогнать. Чемпион по разгону так и делал.

Кстати Страуструп писал, что использование специальных вычислительных массивов из STL позволяет вычислять скалярные произведения в 35 раз быстрее за счет агрессивной оптимизации в компиляторах, кто-нибудь экспериментировал?

[a_schelyaev 366]

Ну собственно, так и мы решили в итоге.

А учитывая тот факт, что ускоряется только сама матричная операция, которая у нас в некоторых задачах может составлять лишь 50% времени от всей итерации, то реальный выигрыш на реальной задаче получается так и вообще 25%.

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

[Fedor 1 597]

Решалки не проблема, хотите бороться, работайте над возможностью языковой, свой компилятор нет смысла писать, а дать возможность управлять программой из с полезно.

Интерфейсы и прочее ориентированное на пользователя съедает намного больше времени.

Выигрыш не в экономии машинного времени, а в совокупном от разговора, до принятия решения.

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

[Гость ISPA]

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

У TESLA C 2070 пиковая производительность 600 Gfl на двойной точности. И памяти 6 Гб. То вам точности не хватало. Потом памяти не хватало. Теперь быстродействия не хватает. Это уже вызывает улыбку.

[a_schelyaev 366]

Не хватало:

1. Памяти.

2. Пропускной способности.

3. Точности.

Полученный двухкратный рост на вещественных двойной точности это еще без учета передачи данных из памяти в GPU. Это только GPU time. Получено на чипе 200 серии. При этом в лучшем случае достигали 60% пропускной способности от пиковой.

Но тут сейчас говорить о чем то все равно бестолку.

Попозже займемся поплотнее, как только рабочий инструментарий на C++ переведут.

[EsDur 0]

У TESLA C 2070 пиковая производительность 600 Gfl на двойной точности. И памяти 6 Гб. То вам точности не хватало. Потом памяти не хватало. Теперь быстродействия не хватает. Это уже вызывает улыбку.

Я не очень понимаю что у Вас улыбку вызывает. У нас сейчас итак двухуровневый параллелизм (MPI + threads) в программах для возможности расчета сверх больших задач на мощных кластерах. У Вас есть это? Если нет, то позвольте улыбнуться в вашу сторону. В 6 Гб задачку 100 млн. вы с неявными методами не решите, это к гадалке не ходи. Для добавления еще одного уровня параллелизма нужны ресурсы и причина. Причина может быть только одна - значительное уменьшение времени счета при использовании граф процессоров. Я много раз слышал о сотне раз ускорения на графических процессорах. Провели сравнение на простейшем тесте для граф процессоров. Разы на оптимизированных производителем библиотеках, сотен раз нет. Разы тоже нужны конечно, но тогда нужны ресурсы для исследования и реализации. Человеческие и финансовые. Вот и все, и нет ничего смешного.

[Fedor 1 597]

"В 6 Гб задачку 100 млн. вы с неявными методами не решите, это к гадалке не ходи" эргодическую теорему как и машину Тьюринга еще никто не отменил, есть же и винчестеры, можно и прямыми, вопрос времени, а не принципа :)

[EsDur 0]

"В 6 Гб задачку 100 млн. вы с неявными методами не решите, это к гадалке не ходи" эргодическую теорему как и машину Тьюринга еще никто не отменил, есть же и винчестеры, можно и прямыми, вопрос времени, а не принципа :)

Федор, вам бы учебники почитать.

Задача ~100млн. 3D объем (например 500x500x500). Памяти нужно для прямого метода ~100 000 000 * 500 * 500~2x10^13 double = 16 Тб. Оптимизация упорядочивания может константу даст. Диски такие найти наверное можно, долго будете с ними работать однако. А мы сейчас такие задачи минуты считаем. Если можете подождать - ждите.

[Гость ISPA]

Я много раз слышал о сотне раз ускорения на графических процессорах. Провели сравнение на простейшем тесте для граф процессоров. Разы на оптимизированных производителем библиотеках, сотен раз нет. Разы тоже нужны конечно, но тогда нужны ресурсы для исследования и реализации. Человеческие и финансовые. Вот и все, и нет ничего смешного.

Если вы много раз слышали, из разных мест, про ускорение в сотни раз, а у вас на тесте не получилось, то это не означает, что люди врут. Но только подумайте, вы человек не глупый. Какой смысл вас обманывать. Может что-то не так в вашем тесте.

Даже на 200 чипе на реальных задачах ускорение в 20-30 раз. На простых тестах 100 раз. Вызывает улыбку, что на тесте ускорение на матричных операциях без учета ввода вывода ускорение 2 раза. Это уже вызывает смех, а не улыбку. Если бы в действительности было ускорение 2 раза, то никто не стал бы тратить времени на переход под GPU.

Вы разберитесь сначала почему фирма заявляет 600 Gfl на двойной точности, а уже потом делайте свой тест. Вас послушать так получается, что NVIDIA весь мир обманывает.

Касаемо расчетов 100 млн. задач. Тогда надо сравнивать кластеры на CPU и на GPU. Сравнить цену, энергопотребление, занимаемые площади, обслуживание. Мне то объяснять не нужно, что под большие задачи нужны большие ресурсы. Улыбку вызывает результаты теста на быстродействие.

[EsDur 0]

Поправочка, нолик упустил, 160 тб

[Fedor 1 597]

Федор, вам бы учебники почитать.

Задача ~100млн. 3D объем (например 500x500x500). Памяти нужно для прямого метода ~100 000 000 * 500 * 500~2x10^13 double = 16 Тб. Оптимизация упорядочивания может константу даст. Диски такие найти наверное можно, долго будете с ними работать однако. А мы сейчас такие задачи минуты считаем. Если можете подождать - ждите.

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

Давно известны схемы хранения разреженных матриц, чего Вы все по себе равняете, есть же и те, кто Кнута листал и Ларкума