NVIDIA CUDA 4.2

Профайлером этим ни разу не пользовался, и надесь не придется, одно слово Visual противно.

новый на основе llvm он был и в 4.1

что из себя код на cuda представляет - это смесь обычного кода для CPU и кода для ядра cuda. Пропускается такой код через связку обычного компилятора и компилятора от cuda.

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

И дистрибутив нужно распространять не в виде адской смеси упакованной в самораспаковывающийся run, а вормальном архиве к примеру xz,

Опять для 6 шапки 32 бита не собрали. Так и буду сидеть на старье для 13 федоры.

К примеру под Gentoo нет сборок, но никто не мешает написать не архисложный сценарий сборки - еbuildы Gentoo, и надежюсь что и под NixOS осилю написание nix-ов. Такое же есть кажется и для rpm, правда очень не удобный язык сценариев у них.

А почему новый нельзя поставить от 14-й федорки?

И дистрибутив нужно распространять не в виде адской смеси упакованной в самораспаковывающийся run, а вормальном архиве к примеру xz

Нет там ничего адского абсолютно

http://megastep.org/makeself/

Профайлером этим ни разу не пользовался, и надесь не придется,

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

Спасибо - не знал, но мне он и так был понятен при просмотре начала файла, там как раз в текстовом виде начало скрипта для запуска распаковки идет.

Но все равно не понимаю зачем самораспаковывающийся под linux, xz лушший компрессор, не зря же его все чаще выбирают для упаковки как ядер так и для исходников.

А почему новый нельзя поставить от 14-й федорки?

ABI другой. Я конечно, попробую при случае, но с 4.1 аналогичное не заработало. Впрочем, новые фичи мне и не нужны.

а никак, пока только изучаю, играюсь. Реальных задач требующих 100 использования пока еще не поступало. Но думаю когда придет их очередь будет альтернатива закрытым изделиям.

А пока пользую для учебы что доступно и работает. Для учебы поиск узких мест не требовался, тем более в Visual виде.

Но при всех равных CUDA всегда быстрее

Упоролся на отличненько.

Что, опять? Сочувствую.

CUDA придумана NVIDIA. Лютым врагом ATI/AMD. Задолго до OpenCL. Вложеные бешеные бабки в раскрутку идеи среди ученых и просто энтузиастов. Если будешь искать пример свободного кода для какой нибудь задачи, хорошо подходящей для архитектуры числодробилки, типа расчета огибания потоков жидкости, и тот же алгоритм пересечения луча с треугльником то 99% наткнешься на хорошо оформленую страничку с логотипом NVIDIA. Не от того что они там такие умные, просто удалось привлечь много внимания, а потом оно само уже. Туча pdf-ок и прочих документов, где они приложили руку. Участие во всяких SIGGRAPH, ну и про суперкомпы на Теслах это уже нарицательное.

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

Разумеется, NVIDIA сделала так де свою поддержку этого «вражеского» стандарта. То есть, на относительно свежих железках от NVIDIA можно запускать как OpenCL так и CUDA.

Теперь расскажи мне, как так AMD умудрилась жидко обделаться, что одна и та же OpenCL программа отлично работает на реализации от NVIDIA и глючит на «родной» AMD. А а надогисный алгоритм переписаный на CUDA выполняется еще быстрее.

То есть, на относительно свежих железках от NVIDIA можно запускать как OpenCL так и CUDA.

А на относительно старых нельзя? =)

алгоритм переписаный на CUDA выполняется еще быстрее

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

Петрошколосян? Ну зажги еще что нибудь более искрометное, еще более вооброжаемое и имеющее еще меньше связи с реальностью. Ты не поверишь, на рива128 OpenCL не запутстить.

алгоритм переписаный на CUDA выполняется еще быстрее

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

Хорошая версия, жизнеенная. Как насчет кривоговноруких драйверописателей от AMD которые не осилили оптимизацию кода, а так же чисто маркетинговое «придержание» каких нибудь оптимизаций чисто для пиара CUDA?

на рива128 OpenCL не запутстить

Я запущу на ней openCL-код сразу, как только ты запустишь на ней куду.

Иди ознакомься с мат.частью, хоть чуть-чуть, дабы больше не позориться тут.

CUDA придумана NVIDIA. Лютым врагом ATI/AMD. Задолго до OpenCL.

GPGPU было реализовано и раскручено ATI раньше nvidia ;) Матчасть учите лучше. CUDA или OpenCL не сильно важно и дело тут в маркетинге, а не технологиях.

Номер версии символизирует.

ага...заодно и драйвер не в бинарном run-блобе, а в нормальном архиве, да ещё и с исходниками =) и чтобы компилировался не только модуль ведра, но ещё и библиотеки ;)

мечты, мечты...

Мне в этом cuda не нравится то, что директива запуска ядра которая «<<<>>>» делает его напрочь несовместимым с C/C++ как таковым, из-за чего и приходится прибегать к этой трансляции в промежуточный код, или как там оно всё происходит...

А ведь могли сделать что-то по типу обычной библиотеки... чтобы функции вызывать и задавать параметры (например, в виде строки хотя бы).

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

Blender может использовать CUDA

Ох если бы...

Для научного софта. Там CUDA стандарт де-факто.

Наука продалась нвидии? Остаётся надеяться, что нвидию не купят какие-нибудь лжеучёные :)

perestoronin> Технология передовая, без альтернатив пока.

4.2

OpenCL есть.

perestoronin> OpenCL может быть и будет когда нибудь гожий, но пока всерьез рано его рассматривать.

Уже давно рассматривают.

perestoronin> Приложений и софта готового мало

Уже достаточно.

perestoronin> Vendor lock будет в одном случае, если программировать будете без абстрагирования от железа через FFI.

CUDA - это уже завязка на нвидии.

anonymous> Для научного софта. Там CUDA стандарт де-факто.

Для научного софта кластеры - стандарт де факто. А CUDA используют сейчас там только потому, что оно раньше появилось. Сейчас все потихоньку сруливают на OpenCL.

Более того - Nvidia Tesla на практике слабее, чем игровая видяха от AMD.

Потому, что к OpenCL приложили руку ребята из нвидии.

anonymous> Так как OpenCL есть жуткое глюкалово в реализации от AMD, реально работает он только на видяхах NVIDIA.

4.2

По производительности AMD Radeon на OpenCL рвёт Nvidia Tesla.

Это ещё ничего не значит.

anonymous> А а надогисный алгоритм переписаный на CUDA выполняется еще быстрее.

Если запускать на нвидии - это так. Потому, что OpenCL там полусофтовый. А если на AMD Radeon - нвидия остаётся в заднице. Это общеизвестный научный факт.

По производительности AMD Radeon на OpenCL рвёт Nvidia Tesla.

На каких задачах, интересно? Или мы просто повторяем вслед за маркетологами?

P.S. Просто насколько я помню (могу ошибаться), AMDшные видеокарты выигрывали на алгоритмах, упирающихся в ALU, которых в физике, например, подавляющее меньшинство.

anonymous> Так как OpenCL есть жуткое глюкалово в реализации от AMD, реально работает он только на видяхах NVIDIA.

4.2

По производительности AMD Radeon на OpenCL рвёт Nvidia Tesla.

GCN 7550/7570 рвет теслы на некоторых избраных тестах, использующих двойную точность чисел с плавающей запятой, так как AMD не стала обрезать эту фичу для в общем то игровой карты. Но говнодрайверы от AMD даже этот успех облажали, хотя времени для вылизывания юыло предостаточно. Только только начиная с каталиста 12.5 они пофиксят свой ушлепский компилятор OpenCL, и он сможет таки компилировать программы (krernels) длиннее 10 строк не по 40 минут сжирая 14 гигабайт памяти.

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

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

Это не биткойны, это столлмановы обручи мозги сжимают. У них же догма: «Открытое/свободное ВСЕГДА лучше проприетарного».

Кому нужен результат, а не процесс, те используют куду.

Ты, как всегда, всё перепутал. Cuda «улучшает» процесс программирования, добавляя быдлокодерские костыли и возможность потыкать мышкой в SDK, а результат выдаёт поганенький - непереносимый и железозависимый.

Большего бреда не слышал, вы молодой человек явно никогда не писали для GPU, и уж тем более научных расчётов.

OpenCL - это не панацея, а бред сивой кобылы. Его ещё пытаются впихнуть в некоторые видеокодеки и граф.недооболочки и Всё. Больше с ним никто не хочет иметь дело.

Те кто пишут под CUDA, прекрасно понимают, что им нежно решение сейчас на текущем закупленном за немалые бабки железе под конкретные задачи. Причём костылей на CUDA никто давно ежу не пишет, они нафиг не нужны с таким объёмом библиотек высокого уровня.

Кроме этого всё явно движется к постепенному открытию CUDA, и одними из явных признаков являются - это переход на LLVM и появление таких открытых библиотек ка Thrust. Посмотри на примеры кода с использованием последней и где ты там найдёшь костыли?

Мне в этом cuda не нравится то, что директива запуска ядра которая «<<<>>>» делает его напрочь несовместимым с C/C++ как таковым, из-за чего и приходится прибегать к этой трансляции в промежуточный код, или как там оно всё происходит...

А ведь могли сделать что-то по типу обычной библиотеки... чтобы функции вызывать и задавать параметры (например, в виде строки хотя бы).

Как говорится «Разделяй и властвуй». Хочешь писать на низком уровне - пиши на чистом CUDA. Хочет отвязаться от всего этого и писать на более высоком уровне - бери и используй библиотеки.

Осваивал GPGPU, первоначально планировал использовать CUDA, купили 560Ti на пробу. Оказалось, что OpenCL вариант работает быстрее (хотя, может быть. у меня руки кривые). К тому же OpenCL существенно понятнее. Теперь будем брать 6 штук 7950.

Для научного софта кластеры - стандарт де факто. А CUDA используют сейчас там только потому, что оно раньше появилось. Сейчас все потихоньку сруливают на OpenCL.

А чем подтвердишь? Ссылочку, ссылочку в студию!!!

OpenCL - это не панацея, а бред сивой кобылы.

С вами никак не можно согласиться. OpenCL --- это достаточно хорошо продуманный международный стандарт. CUDA --- технология отдельной компании, сильная наличием большего числа библиотек. Как только основные библиотеки портируют на OpenCL, преимущества Куды практически нивелируются.

Причём костылей на CUDA никто давно ежу не пишет, они нафиг не нужны с таким объёмом библиотек высокого уровня.

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

Кроме этого всё явно движется к постепенному открытию CUDA

Может произойти только в 1 случае: если CUDA станет проигрывать рынок, иначе это комерчески невыгодно.

Мне в этом cuda не нравится то, что директива запуска ядра которая «<<<>>>» делает его напрочь несовместимым с C/C++

В каком смысле несовместимым? В .cu файлах можно хоть boost.spirit'ом пользоваться (под g++).

метод наименьших квадратов

Всё зависит от функции, но скорее всего тебе сюда http://code.google.com/p/thrust/wiki/QuickStartGuide#Reductions

генерация нормально распределённых и хи-квадрат распределённых случайных чисел

Начал бы от сюда http://developer.nvidia.com/cuRAND, как минимум нормальное распределение там есть

По остальному искать мне лень.

вы молодой человек явно никогда не писали для GPU

Где можно скачать исходники твоих проектов?

OpenCL - это не панацея, а бред сивой кобылы. Его ещё пытаются впихнуть в некоторые видеокодеки и граф.недооболочки и Всё. Больше с ним никто не хочет иметь дело.

Те кто пишут под CUDA, прекрасно понимают

Отличная у тебя аргументация, сынок. Отдел маркетинга будет тебе рад.

это не чистый cuda. это cuda runtime api :) есть ещё cuda driver api, там таких штук нет... но там надо много больше телодвижений...

наверное, всё это из-за самой ущербности C, совместимость с которым так хотели сохранить... лучше бы придумали свой язык, несовместимый.

В том смысле, что нельзя скомпилить при помощи что-то вроде «gcc --всякие_флаги --lib-cuda», например... (ключ выдумал из головы). Только всякие костыли вроде nvcc.

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

Плюсую... я тоже многого не нашёл, придётся свои велосипеды писать...

а мне нужно - преобразование лапласа (фурье вроде бы есть, надо попробовать его), вроде есть curand, надо бы тоже это задействовать... и cublas.

для opencl этого вроде тоже ничего нет

Речевое манипулирование ?

Оно без цифр - пустой звук. Поэтому не буду сам опровергать ничего.

Жду цифр чтобы увидеть что OpenCL на 7960 вообще годно для ускорения хотя бы в два раза в сравнении с мощным CPU работающим на 3.3ГГц.

Все верно - прикладное ПО на языках прикладного значения, а связь с железом через FFI.

Очень редко бывает необходимость прикладное ПО писать на Си и ассемблере. А вот выносить слабые места в отдельные свои библиотеки на Си, nvcc или ассеблер - это правильно, при условии что нет готовых или они не устраивают. Таким образом можно избежать «Vendor lock».

Vendor lock будет в одном случае, если программировать будете без абстрагирования от железа через FFI.

Все верно - прикладное ПО на языках прикладного значения, а связь с железом через FFI. Таким образом можно избежать «Vendor lock».

Ну как ты своим FFI заставишь работать куда-код на железе, не произведённом Нвидией?

В том смысле, что нельзя скомпилить при помощи что-то вроде «gcc --всякие_флаги --lib-cuda», например... (ключ выдумал из головы). Только всякие костыли вроде nvcc.

nvcc понадобиться только для компиляции *.cu файлов содержащих вычислительные ядра для GPU, на что и не рассчитан gcc.

Всё остальное компиль чем хочешь. А если ты используешь дополнительные библиотеки, то никаких nvcc тебе нафиг и не понадобиться.

Ещё лучше вообще воспользоваться QMake для сборки проекта. Он сам легко разбирается что к чему.

Жду цифр чтобы увидеть что OpenCL на 7960 вообще годно для ускорения хотя бы в два раза в сравнении с мощным CPU работающим на 3.3ГГц.

К сожалению, с вами невозможно поспорить, ведь нет ни одной видеокарты с индексом 7960, а на частоте 3,3ГГц работает море процессоров от старых 4 пней с гипертрейдингом ещё на микроархитектуре NetBurst, до современных Core i3, Core i5, FX-6100 и многих других (кстати, старый добрый E8600 тоже попадает под это определение). Вы сначала поставьте задачу грамотно и чётко, аргументируйте свою постановку, потом спрашивайте с других конкретные цифры. В моём случае (E6550 и GeForce 560Ti) преимущество в ряде наиболее тяжелых вариантов задачи достигало 3,5 раз при использовании двойной точности.

dmfd> На каких задачах, интересно? Или мы просто повторяем вслед за маркетологами?

На задачах молекулярной динамики с потенциалом внедрённого атома.

anonymous> Но говнодрайверы от AMD даже этот успех облажали

Нифига не облажали. Более того - драйверы от AMD сейчас уже качественнее драйверов от нвидии. Это факт.

AlexVR> А чем подтвердишь? Ссылочку, ссылочку в студию!!!

Гугли «Porting LAMMPS OpenCL». Там в статейке и диаграммы приводятся, согласно которым нвидия отстаёт.

И ещё на заметку: LAMMPS под нвидию изначально оптимизировали. Так что даже при этом козыре нвидия слила.

Нет. Увы, не только сами вычислительные ядра. Но и «директивы» запуска этих ядер..

С qmake постараюсь разобраться, если время останется