NVidia CUDA 1.1 released

lexa - 12/Дек/2007 10:26
Вышла NVidia CUDA 1.1

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

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

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

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

Comments

Anonymous (not verified) - 12/Дек/2007 10:49

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

lexa - 12/Дек/2007 15:20

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

интернет бизнес (not verified) - 15/Дек/2007 19:32

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

Radiohead (not verified) - 26/Дек/2007 01:41

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

lexa - 26/Дек/2007 09:12

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

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

Anonymous (not verified) - 26/Дек/2007 14:22

Да, действительно - фолдинг на настоящий момент единственный из известных мне проектов которые использует 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 уже есть (бета). И его можно "пощщупать руками" :-)
Если интересно - могу обьяснить как...

lexa - 26/Дек/2007 14:35

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

Anonymous (not verified) - 26/Дек/2007 14:55

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

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

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

mrshurik (not verified) - 14/Дек/2007 12:02

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

lexa - 14/Дек/2007 12:08

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

mrshurik (not verified) - 14/Дек/2007 12:20

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

lexa - 14/Дек/2007 14:05

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

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

mrshurik (not verified) - 14/Дек/2007 14:43

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

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

lexa - 14/Дек/2007 15:40

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

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

mrshurik (not verified) - 14/Дек/2007 17:30

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

lexa - 14/Дек/2007 17:53

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

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

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

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

mrshurik (not verified) - 14/Дек/2007 18:42

>>Для потокового процессора или для системы с локальной памятью оно программируется принципиально по-разному
разница в том, что для 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 архитектур.

lexa - 15/Дек/2007 03:20

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

mrshurik (not verified) - 15/Дек/2007 08:34

из мануала "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.

lexa - 15/Дек/2007 09:04

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

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

mrshurik (not verified) - 15/Дек/2007 09:37

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

моя посылка - при программировании в 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 есть программный кэш, реализованный через отдельную библиотеку. подключаете её и получаете кэш. не такой эффективный как железный, но всё равно.

lexa - 15/Дек/2007 10:25

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

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

mrshurik (not verified) - 15/Дек/2007 11:25

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

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

у б) другие задачи - посредник между 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. надо иметь аккаунт для просмотра. в общем, это фишка компилятора.

lexa - 15/Дек/2007 11:55

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

mrshurik (not verified) - 15/Дек/2007 12:19

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

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

lexa - 15/Дек/2007 12:26

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

mrshurik (not verified) - 15/Дек/2007 12:58

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

lexa - 15/Дек/2007 13:13

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

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

mrshurik (not verified) - 15/Дек/2007 15:45

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

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

vasionok (not verified) - 26/Дек/2007 01:43

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