NVidia CUDA

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

SGEMM/DGEMM на видеокарте и CPU, серия 7: NVidia GTX280
В чипе NVidia G200 появились операции с двойной точностью. Их производительность не феноменальна, но даже с учетом ввода-вывода данных в карту GTX280 обгоняет 4-ядерный 3-гигагерцовый Penryn. Если же рассматривать только скорость вычислений (что актуально, если задача позволяет спрятать затраты на ввод-вывод), то на двойной точности видеокарта быстрее CPU в 1.8 раза.
На одинарной точности разрыв видеокарты и CPU вырос: GTX280 обгоняет Core2Quad впятеро.

Понятно, что Core i7 разницу несколько сократит, но по тем бенчмаркам с плавающей точкой, что я видел (а видел я пока только Linpack, причем не факт что в оптимальном для i7 виде), рост в производительности i7 - процентов 20.

Всякие соображения про масштабируемость решения - в самой статье.

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

SGEMM/DGEMM на видеокарте и CPU, серия 7: NVidia GTX280
В чипе NVidia G200 появились операции с двойной точностью. Их производительность не феноменальна, но даже с учетом ввода-вывода данных в карту GTX280 обгоняет 4-ядерный 3-гигагерцовый Penryn. Если же рассматривать только скорость вычислений (что актуально, если задача позволяет спрятать затраты на ввод-вывод), то на двойной точности видеокарта быстрее CPU в 1.8 раза.
На одинарной точности разрыв видеокарты и CPU вырос: GTX280 обгоняет Core2Quad впятеро.

Понятно, что Core i7 разницу несколько сократит, но по тем бенчмаркам с плавающей точкой, что я видел (а видел я пока только Linpack, причем не факт что в оптимальном для i7 виде), рост в производительности i7 - процентов 20.

Всякие соображения про масштабируемость решения - в самой статье.

Совершенно случайно узнал, но не могу пройти мимо не анонсировав.

NVidia (совместно с iXBT, как я понял) проводит конкурс программ для CUDA, как положено с призами.

Конкурс проводится среди разработчиков из России и СНГ, а значит шансы выиграть достаточно высоки (ибо потенциальных участников мало).

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

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

Вышла бета версия NVidia CUDA for Mac OS X. На удивление, сразу в публичный доступ, через девелоперский сайт прогонять не стали.

Естественно, требует Мака с видеокартой NVidia 8xxx. Менее естественно, но требует Leopard 10.5.2 и установленного Leopard Graphic Update. Так как все это у меня было, я слегка поигрался.

Выводы:

• Все примеры вроде работают.
• 8600M - довольно медленная карта, разница в скорости в сравнении с 8800GTX от двух до восьми раз, чем лучше сделано приложение, тем больше разница. И если простые потоковые вычисления очевидно имеет смысл тащить на видеокарту, то с чем-то более сложным уже не факт. Например, пример historgram256 работает на CPU быстрее, чем на видеокарте (790Mb/sec против 850. 8800GTX считает ту же гистограмму со скоростью 5.4Gb/sec).
• 128 мегабайт видеопамяти - это очень мало. Для тех же примеров с гистограммами пришлось размер данных уменьшать со 100 мегабайт до 20. Если вспомнить, что одна из идей была - перенести процессинг графики на видео, а 20-мегапиксельный файл - это 80 мегабайт, то становится немного грустно.

Свершилось, теперь вполне можно выпускать реальные приложения для end-users, а в требованиях спокойно писать "Windows XP, Geforce 8xxx, официальные драйвера 169.+".

Кто бы глянул, есть ли nvcuda.dll в комплекте драйверов для Vista.....

Несмотря на некруглый номер версии, это революция:

• CUDA-функциональность теперь будет в обычном драйвере;
• Необходимые DLL-s из SDK можно редистрибутировать вместе с приложением;

По сути, это означает, что из тестовой системы оно стало боевой: в требованиях к программе можно писать просто NVidia 8x00 и минимальную версию (обычных!) драйверов и у любого пользователя оно будет работать.

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

Почему переделываем тесты?

За прошедшие полгода, пока я занимался совсем другими вещами, были выпущены релизы:

• NVidia CUDA: SDK и библиотеки CUBLAS/CUFFT v1.0;
• NVidia CUDA Display Driver 162.xx (драйвер, собственно, транслирует псевдокод в реальные программы GPU);
• RapidMind Platform версий 2.0.0, а затем и 2.0.1.

Интересно посмотреть, стала ли производительность лучше.

Опуская обычные охи "ну почему этому не учат на ВМК" - все в наших руках и я думаю, что через пару лет такие курсы будут и у нас, тема вкусная - хочу обратить внимание на слайды и транскрипты лекций, доступные вот тут. Читают приглашенные лекторы из NVidia, поэтому основное внимание уделено, сюрприз, NVidia 8800. Курс включает в себя лабы, которые сделаны очень интересно: есть готовая рыба, делающая подготовительную работу (I/O, печать результаты) и студент должен только написать несколько десятков-сотен строк изучаемой функциональности. Что, конечно, экономит кучу непроизводительного времени (смотреть тут)

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

Нравится, как практику, подробный разбор аппаратуры. Вылезает множество подробностей, которые нигде не опубликованы.

Вот о подробностях - ниже.

Из общих соображений, понятно что самая медленная часть суперкомпьютера - память. С одной стороны, теоретическая пропускная способность (bandwidth) составляет 900MHz * 384 бита * 2 (DDR) = 86.4 GB/sec. С другой стороны, раздел 6.1.1.3 руководства говорит о 200-300 циклах memory latency (при, по всей видимости,случайном доступе).

К счастью, проблема легко изучается: если взять достаточно много данных (скажем, полгигабайта) и, например, сложить все 4-байтовые значения (как float), то основные затраты времени будут именно на чтение из памяти, а всей прочей арифметикой можно пренебречь (или подсчитать ее отдельно).

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