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

[Гость ISPA]

Вопрос о скорости вашего модифицированного под ГПУ решателя остается открытым.

Определите скорость решателя в Гфл и результат обсудим на форуме.

[Eugeen 6]

Вопрос о скорости вашего модифицированного под ГПУ решателя остается открытым.

Определите скорость решателя в Гфл и результат обсудим на форуме.

Есть такая птица - глухарь. Названа так потому, что на току она слышит только себя, за это прекрасное качество ее и ценят охотники (не говоря уже о кулинарных качествах).

Я Вам талдычу про 700 ГФ, которые карта обеспечивает, а не про то сколько наши проги могут из этого задействовать. Я пишу о принципах ускорения, а Вы пытаетесь здесь убедить что GPU бесперспективны и только Ваш путь единственно правильный.

О BLAS. У нас есть все варианты использования BLAS - и на CPU и на GPU.

На той задаче, о которой я писал выйгрыш в скорости небольшой у GPU.

Причем детальный анализ показывает довольно большое расхождение между скоростью CUDABLAS и AMDBLAS (в пользу первого). Хотя AMDBLAS и на PCI-e3 и карта быстрее (7950 против 680). Запросы в AMD пока ответов не имеют, там думают.

Все это говорит о том, что их софт еще сыроват, но люди работают на ним.

Кстати говоря, я так и нигде не увидел ссылок на Ваш-то метод решения СЛАУ с разреженными матрицами?

[Гость ISPA]

Я Вам талдычу про 700 ГФ, которые карта обеспечивает, а не про то сколько наши проги могут из этого задействовать.

Это вы не слышите. Напишите ту скорость которую задействует ваша программа.

Это что военная тайна.

Объясняю еще раз, скорость в 700 Гфл - это пиковая скорость устройтва при работе с маленькими матрицами. К решению уравнений не имеет отношения.

О BLAS. У нас есть все варианты использования BLAS - и на CPU и на GPU.

На той задаче, о которой я писал выйгрыш в скорости небольшой у GPU.

Напишите скорость вашей программы на CPU и на GPU.

Кстати говоря, я так и нигде не увидел ссылок на Ваш-то метод решения СЛАУ с разреженными матрицами?

У меня нет своего метода решения СЛАУ. Поэтому и нет ссылок.

У меня реализован Холецкий. Скорость не заисит от метода решения, а зависит от программной реализации.

Напишите скорость вашей программы на CPU и на GPU.

И кто из нас глухарь.

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

Этот вопрос был в Сообщение #646

[Гость ISPA]

1. Алгоритм факторизации матриц не является высоко параллельным. Поэтому, теоретическую (максимальную) скорость видео устройства достичь невозможно.

2. Скорость работы с видео и оперативной памяти примерно одинаковая. И это довольно медленная память. Поэтому, даже если все данные разместить в видео памяти, то скорость работы с этими данными будет низкая. Быстрой памяти всего 64 000 байт на все графические ядра.

3. Каждый раз при выполнении команды приходится запускать графические ядра. И синхронизировать их работу. На это уходит много времени.

4. Нельзя параллельно выполнять несколько команд. Например, нельзя параллельно перемножать несколько матриц. Только последовательно.

5. Данные в видео память и обратно передаются по шине, а это очень медленно.

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

Раз в 10-15 меньше от теоретически возможной.

Так что 700 Гфл - это хороший рекламный ход.

[a_schelyaev 366]

Кстати, приоткройте секрет: OpenCL или DirectCompute?

Пока смотрим CUDA, но в будущее готовимся идти под OpenCL.

А что там уже будет на выходе - время покажет.

У процессора Интел появились регистры размером 256 бит, 4 double, до этого были 128 бит.

За 1 такт делается операция с 4 double.

Ну это известная же тема.

Так все таки, ускорение обеспечивается ручками или ключами в компиляторе?

Есть такая птица - глухарь.

Какое-то время назад, когда ИСПА причмокивал на тему GPU, то я указывал на узкое место в виде пересылки данных в GPU, на что он предлагал идти штрудировать CUDA.

Прошло время и теперь он сам уже про это всем песни поет.

[Гость ISPA]

Какое-то время назад, когда ИСПА причмокивал на тему GPU, то я указывал на узкое место в виде пересылки данных в GPU, на что он предлагал идти штрудировать CUDA.

Прошло время и теперь он сам уже про это всем песни поет.

Дело в том, что в ИСПА реализован эффективный итерационный алгоритм решения СЛАУ. Данные во время итераций вообще не пересылаются ни туда ни обратно.

Поэтому и эффелтивный.

А перед эти я писал о полной факторизации на ГПУ.

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

<noindex>http://www.ispa-soft.ru/statxi/statxq16.htm</noindex>

Какое-то время назад, когда ИСПА причмокивал на тему GPU

Зовите меня просто - господин ISPA.

[a_schelyaev 366]

Тема про регистры не раскрыта, но в целом, вроде, понятно, что ничего сакрального там нет и все дело в размере блока. А дальше уже комплиятор куда надо приведет.

Боян, короче.

[Гость ISPA]

Тема про регистры не раскрыта, но в целом, вроде, понятно, что ничего сакрального там нет и все дело в размере блока. А дальше уже комплиятор куда надо приведет.

Боян, короче.

Компилятор не поможет. Я не знаю такого компилятора.

Все ручками надо делать. На ассемблере.

А Баян у того кто песни поет.

[a_schelyaev 366]

Компилятор не поможет. Я не знаю такого компилятора.

Наши "помогают" компилятору через структуру кода.

Интеловские профилировщики-то используете?

[Гость ISPA]

Наши "помогают" компилятору через структуру кода.

Интеловские профилировщики-то используете?

Нет.

Зря я про рыбные места стал рассказывать.

[a_schelyaev 366]

Копаться в ассемблере под каждую модель процессора моветон.

[Гость ISPA]

Копаться в ассемблере под каждую модель процессора моветон.

Так у меня выбора нет.

Или скорость 1.5 Гфл на 1 яжре (сопроцессор) или 20 Гфд на том ядре (ассемблерная вставка).

Ансис же ускоряет свой решатель используя ассемблер. В Ансис очень быстрый решатель.

А чем ИСПА хуже. Правильно, уже ничем.

Вот этапы большого пути

<noindex>http://www.ispa-soft.ru/statxi/statxq15.htm</noindex>

<noindex>http://www.ispa-soft.ru/statxi/statxq16.htm</noindex>

<noindex>http://www.ispa-soft.ru/statxi/statxq17.htm</noindex>

<noindex>http://www.ispa-soft.ru/statxi/statxq18.htm</noindex>

[a_schelyaev 366]

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

Насчет того, что Ансис заказал консалтинг чуть-ли не у Интела по тюнингованию своей решалки я слышал, но разработчики такой вариант начисто отвергают, т.к. это удорожает разработку.

Под каждый новый процессор опять начинать оптимизацию снова.

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

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

[Гость ISPA]

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

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

У вас, что скорость на 1 ядре 20 Гфл, а на 6 ядрах 80.

Вы нпишите скорость своей решалки и размерность матрицы.

[a_schelyaev 366]

Мне проще дождаться очередной презентации от Сарова, чем ходить с протянутой рукой среди разработчиков. Да и в флопах у нас точно не измеряют обычно, только в количестве итераций и времени выполнения.

:)

[Гость ISPA]

Да и в флопах у нас точно не измеряют

[a_schelyaev 366]

У нас секретарь тоже смеется в самых неожиданных местах.

Мы привыкли.

[Гость ISPA]

Чудак-человек.

<noindex>http://ru.wikipedia.org/wiki/FLOPS</noindex>

[Гость ISPA]

Копаться в ассемблере под каждую модель процессора моветон.

Не нужно копаться. Ассемблерная вставка для сопроцессора, в ИСПА, не меняется с 1997 года.

Сам дурак!

Читайте еще раз букварь.

<noindex>http://ru.wikipedia.org/wiki/FLOPS</noindex>

[a_schelyaev 366]

Не нужно копаться. Ассемблерная вставка для сопроцессора, в ИСПА, не меняется с 1997 года.

Тогда вообще ничего непонятно - если ассемблерная вставка не меняется, а типы процессоров с того года менялись и очень значительно, то что же там вставлено?

Почищено. (Борман)