NVidia CUDA 1.1 released

Вышла NVidia CUDA 1.1

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

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

Из интересных проектов с CUDA увидел два:

  • Texture Tools от Гугла, которые обещают офигенно быструю texture compression, аж в 12.5 раз быстрее. Гейм-девелоперам будет приятно.
  • PyStream - Python interface to CUDA. Жизнь там пока вялая, но идея интересная.

Comments

обещали сильно уменьшить задержки, но что-то незаметно
как было порядка 10 микросекунд, так и осталось
может я чего-то не понимаю

зато асинхронный режим появился

Простите, но что это .

Что вы можете сказать на счет возможности применения GPGPU в распределенных вычислениях?
Лично меня интересует вот это - http://lunatics.kwsn.net/gpu-crunching/index.0.html

Насколько я знаю, в какой-то распределенной сети основные терафлопсы дают именно видеокарты (но это кажется не seti@home, а folding@home)

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

Да, действительно - фолдинг на настоящий момент единственный из известных мне проектов которые использует GPU для своих расчетных задач.
Но есть два момента:
1 - они используют игровые консоли Sony PS3. И именно эти консоли показывают просто подавляющее превосходство над всеми остальными системами. http://fah-web.stanford.edu/cgi-bin/main.py?qtype=osstats
Но ведь PS3 - это "не совсем GPU"? Или я не прав?
2 - так-же есть клиент для некоторых моделей GPU ATI (старых моделей). Но из-за несовершенства программной части эти клиенты не дают практически никаких преимуществ.
При этом разработчики фолдинга по непонятным причинам абсолютно игнорируют Nvidia и CUDA...

В сообществе seti наоборот ведут разработки именно для Nvidia. Сначала работали с RapidMind, но столкнулись с некоторыми проблемами... Теперь накопленный опыт переносят на CUDA.
К сожалению для seti нужна двойная точность...

З.Ы.
Кстати клиент seti с использованием CUDA уже есть (бета). И его можно "пощщупать руками" :-)
Если интересно - могу обьяснить как...

Если поделить терафлопсы на количество участников, то вклад в расчете на 1 GPU гораздо больше, чем на playstation

Я на это и надеюсь :-) Но только не в плане использования ATI, а в плане Nvidia для Seti.

Хотя вообще-то с ATI ситуация неясная...
Судя по отзывам тех кто пытался запускать клиента ATi для фолдинга - производительность SMP+GPU ниже чем чистый SMP...

З.Ы.
Кстати тесты беты GPU-клиента для seti так-же показывают низкую производительность. 8800GTS 320 на 5-50% (зависит от блока данных) медленней чем одно ядро C2D E6600.
Но там есть где оптимизировать...
Сейчас разработчики пытаются просто добится 100% точности результатов. И только после этого займутся оптимизацией и подьемом производительности.

ИМХО CUDA хороша как библиотека функций (BLAS, FFT), но для программирования своих алгоритмов лучше использовать Brook.

Brook не дает доступа к shared memory и прочим фишкам CUDA. А это огромная разница во всем.

ну это вопрос runtime Brook, доступ может быть неявный.
зато у Brook есть много других плюсов, можно писать элегантные программы не заточенные под какую-либо конкретную архитектуру.
я бы сравнил Brook с High-Level language для GPU (С++/STL), а CUDA - это C код со вставками ассемблера.
под каждую новую архитектуру (чип) придется править код. все оптимизации приходится делать вручную, никаких generic алгоритмов. ИМХО серьезные программы писать очень сложно и поддерживать их потом еще сложнее.

Ну подождите. У CUDA есть local storage, у другого оборудования - нету. У CUDA можно писать в произвольный адрес памяти, у остальных - только поток (+-MRT). Это приводит к принципиально-разным алгоритмам, которые на уровне рантайма нельзя свести к одному представлению.
Ну давайте представим себе хоть гистограмму что-ли (хе-хе, напишите это на потоке).

В том что касается архитектуры, NVidia приложила в это место массу усилий, они собираются масштабировать путем увеличения числа SP (т.е. просто распараллеливать) и этот путь - хороший и правильный.

в Brook управление памятью происходит динамически. где в конкретный момент находится поток пользователь не знает, это может быть CPU RAM, GPU RAM, GPU cache и т.д. runtime выделяет/перемещает данные по необходимости, где удобнее.

еще вопрос по RapidMind, пытался скачать trial, но не нашел как это сделать на сайте. подскажите пожалуйста где именно.

Ну чудес то не бывает. Вот банальное умножение матриц. На "обычном GPU" надо делать блоками 4x4, а на cuda - 16x16 или 32x32. И никакой компилятор одно в другое не перепишет, чудес не бывает. Аналогично со scatter - в DX/GL его нет, а счастья может быть много.

А RapidMind похоже с открытого сайта все убрал и регистрацию девелоперов прикрыл. Не знаю почему.

в том-то и прелесть подхода с runtime, что разбиение на блоки выбирается в момент исполнения и может адаптироваться под архитектуру. не надо даже перекомпилировать ничего.
как я уже писал, по аналогии - на ассемблере всегда можно написать более быстрый код, в том числе за счет использования фич конкретного железа (scatter). но писать этот код очень сложно и он "привязан" к железу.
в ваших тестах BLAS3 CUDA vs RapidMind видно, что производительность CUDA не намного выше RapidMind, зато последний вариант легко портируется на любую видеокарту.
по поводу RapidMind. а не могли бы вы её выложить куда-нибудь,если у вас сохранилась? или может быть ссылка есть?

Тут коротким ответом не отделаешься.
SGEMM - действительно, при такой скорости памяти уже нет принципиальной разницы между блоками 4x4 (rapidmind) и блоками побольше. Ну так и задача не требует scatter и локальной памяти, можно в регистры распихать.

Но возьмите любую непрямолинейную задачу. Гистограмму или сортировку. Для потокового процессора или для системы с локальной памятью оно программируется принципиально по-разному. И никакие автоматические средства не сменят алгоритм. Огромное количество вещей на CUDA просто пишется иначе - это именно другая архитектура и никуда не деться.

Заметим, что у RapidMind, где подход близок к Brook, *разный код* умножения матриц для Cell и для GPU. На Cell блоки 4x8, на GPU - 4x4.

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

>>Для потокового процессора или для системы с локальной памятью оно программируется принципиально по-разному
разница в том, что для Brook локальная память на процессорах внутри G80 явно не видна, она фактически кеш, его логика управляется DX API, как и при нормальном режиме работы с графикой. конечно, можно добавить в алгоритм явное использование этой памяти и тогда он будет отличаться от алгоритма, который её не видит. но не для каждого алгоритма это будет эффективнее, чем работа в режиме кеш.
принципиальная разница будет в парадигме, как если реализовать один и тот же алгоритм через систему классов или написать его в функциональном стиле.
подход CUDA к параллелизации это развитие подхода OpenMP - параллелизация без изменения парадигмы языка (C), есть другой подход - Intel TBB (generic-like параллелизация). делать параллелизацию в TBB проще, безопаснее и она получается более высокого уровня, динамическая (тоже есть runtime), но не такая эффективная для простых алгоритмов, как OpenMP. поэтому Intel использует OMP для библиотек (Intel IPP, Intel MKL, ...), а для программирования на высоком уровне советует TBB.
примерно тоже мы имеем с CUDA и stream programming, разные парадигмы. CUDA ближе к железу, но stream programming удобнее, безопаснее, переносимее и т.д.
лично я считаю, что будущее GPGPU именно за stream programming, т.к. данный стиль программирования проще и благоприятствует для massive parallel архитектур.

Какие кэши ? Кто заботится об их когерентности ? Какой от них толк в потоковой парадигме ?

из мануала "CUDA features a parallel data cache or on-chip shared memory with very fast general read and write access, that threads use to share data with each other". когда работают обычные DX приложения эта shared memory работает именно как кеш, т.к. в спецификациях DX нет понятия памяти, кроме обычной GPU RAM.
как реализована когерентность не знаю, либо аппаратно, либо программно (как в Cell). это не так важно. главное, что экономится канал до основной памяти.
>>Какой от них толк в потоковой парадигме?
потоковая парадигма не имеет ничего против кеша, как и во всех других случаях кеш позволяет повысить bandwidth, уменьшить задержки и т.п. в потоковой парадигме ведь тоже может быть data reusege.

Там есть отдельный текстурный кэш. А использовать в потоковой парадигме shared memory на SP - мне непонятно как. Там нету data reuse (кроме регистров, которые отдельные)

В Cell когерентность никак не реализована, кстати. Там юниты независимые и вообще все на CUDA очень похоже.

мы (я) уже запутались в посылках :-)

моя посылка - при программировании в Brook вообще не важно где что находится, об этом думает runtime из соображений эффективности. далее, при работе такого кода на G80 будут использоваться все кеши и памяти, т.к. работа идет через DX API, а он явно использует все кеши (иначе они были бы бесполезны и их туда не поставили). такое использование shared memory можно назвать кэшем, т.к. для приложения оно прозрачно. как при этом работает этот "кэш" я точно не знаю.

про потоковые процессоры и парадигмы. ну почему нет data reuse? без data reuse современные ALU не накормишь. простым алгоритмам из графики достаточно регистров, у более-менее сложных алгоритмов (в т.ч. geometric shaders из DX10) GPGPU локальность доступа превышает размер регистрового файла. здесь как раз нужны кеши. это немного против идеологии "потоковости", но ближе к практике. многие считают, что CPU и GPU будут всё более и более сближаться по архитектуре и GPU фактически превратятся из stream processor (очень маленькие кэши, много ALU, простые однопроходные алгоритмы) в massive parallel processor (много ALU, среднего размера кэши, алгоритмы со сложными ветвлениями).

в Cell есть программный кэш, реализованный через отдельную библиотеку. подключаете её и получаете кэш. не такой эффективный как железный, но всё равно.

Моя посылка в том, что
а) программировать без учета архитектуры - это терять десятки процентов производительности (т.е. в худшем случае - десятки раз, если по большей скорости считать)
б) runtime - это здорово, но если вдруг взбрело самому реализовать, скажем, сортировку то никакой компилятор/рантайм не сделает из моей реализации bitonic sort мою же реализацию qsort (или наоборот)
Конечно, если можно все сбросить на библиотеку (написанную руками и под конкретную архитектуру), то все отлично.

А про "программный кэш на Cell" хочу почитать.

я согласен с а) и б).

но согласитесь, что программировать в а) удобнее и быстрее.

у б) другие задачи - посредник между low-level API (DX, OGL, videodriver) и high-level языком вроде Brook. на runtime ложится задача оптимизации к железу. ясно, что эта оптимизация не может быть выполнена идеально.

http://www.ibm.com/developerworks/edu/pa-dw-pa-cbecompile5-i.html?S_TACT...
Software Caching in more details. надо иметь аккаунт для просмотра. в общем, это фишка компилятора.

Я почитал. Это же то самое ручное программирование, против которого вы возражаете.

вы читали только затравку или сам pdf?

в Cell есть 2 альтернативы - либо работаешь с Local Store сам, либо включаешь специальный флаг компилятора и все подгрузки - выгрузки делаются автоматически, те реализуется software cache. в документе всё подробно описано.

Я читал PDF, правда быстро.
Там написано, как ручками сделать оный software cache (на 17-й странице).

это я не ту ссылку дал :-)
в том документе вначале объясняется Automatic memory management on the SPE, который реализуется компилятором, а потом как альтернатива - "ручной" кэш в разделе Software Caching in more details.

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

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

ок, почитаю внимательнее. может я что не так понял.

спасибо за дискуссию.

4x4 слишком мало для GPU. На GPU не только память быстрая, но и арифметика. Поэтому блоки должны быть здоровые. К сожалению, размер блока упирается в мизерный размер локальной памяти. Поэтому SGEMM и достигает всего лишь ~35% пиковой арифметической производительности.

Add new comment