Свежие комментарии

Title	Comment
) так и есть )	) так и есть )
Простите, но что это .	Простите, но что это .
ок, почитаю внимательнее. может я что не так понял. спасибо	ок, почитаю внимательнее. может я что не так понял. спасибо за дискуссию.
Вначале там про оверлеи (код). Ну да, это действительно мног	Вначале там про оверлеи (код). Ну да, это действительно много лет уже автоматически умеют делать, ибо зависимости между кодом не вычисляются на ходу (в отличие от данных) и оттого легко автоматизируются. А вот про данные ничего вразумительного про автоматику не написано.
это я не ту ссылку дал :-) в том документе вначале объясняет	это я не ту ссылку дал :-) в том документе вначале объясняется Automatic memory management on the SPE, который реализуется компилятором, а потом как альтернатива - "ручной" кэш в разделе Software Caching in more details.
Я читал PDF, правда быстро. Там написано, как ручками сделат	Я читал PDF, правда быстро. Там написано, как ручками сделать оный software cache (на 17-й странице).
вы читали только затравку или сам pdf? в Cell есть 2 альтер	вы читали только затравку или сам pdf? в Cell есть 2 альтернативы - либо работаешь с Local Store сам, либо включаешь специальный флаг компилятора и все подгрузки - выгрузки делаются автоматически, те реализуется software cache. в документе всё подробно описано.
Я почитал. Это же то самое ручное программирование, против к	Я почитал. Это же то самое ручное программирование, против которого вы возражаете.
я согласен с а) и б). но согласитесь, что программировать в	я согласен с а) и б). но согласитесь, что программировать в а) удобнее и быстрее. у б) другие задачи - посредник между 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. надо иметь аккаунт для просмотра. в общем, это фишка компилятора.
А как можно тянуть "серп без внутреннего содержимого" ? Там	А как можно тянуть "серп без внутреннего содержимого" ? Там же директ на той же странице...
Моя посылка в том, что а) программировать без учета архитек	Моя посылка в том, что а) программировать без учета архитектуры - это терять десятки процентов производительности (т.е. в худшем случае - десятки раз, если по большей скорости считать) б) runtime - это здорово, но если вдруг взбрело самому реализовать, скажем, сортировку то никакой компилятор/рантайм не сделает из моей реализации bitonic sort мою же реализацию qsort (или наоборот) Конечно, если можно все сбросить на библиотеку (написанную руками и под конкретную архитектуру), то все отлично. А про "программный кэш на Cell" хочу почитать.
мы (я) уже запутались в посылках :-) моя посылка - при прог	мы (я) уже запутались в посылках :-) моя посылка - при программировании в 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 есть программный кэш, реализованный через отдельную библиотеку. подключаете её и получаете кэш. не такой эффективный как железный, но всё равно.
Там есть отдельный текстурный кэш. А использовать в потоково	Там есть отдельный текстурный кэш. А использовать в потоковой парадигме shared memory на SP - мне непонятно как. Там нету data reuse (кроме регистров, которые отдельные) В Cell когерентность никак не реализована, кстати. Там юниты независимые и вообще все на CUDA очень похоже.
из мануала "CUDA features a parallel data cache or on-c	из мануала "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.
Какие кэши ? Кто заботится об их когерентности ? Какой от ни	Какие кэши ? Кто заботится об их когерентности ? Какой от них толк в потоковой парадигме ?
Alex, вообще-то Яндекс должен показывать рекламодателям в да	Alex, вообще-то Яндекс должен показывать рекламодателям в данной статистике количество банеропоказов. А нормальные боты должны тянуть SERP без внутреннего содержимого, включая код direct'а. Т.е очень даже может быть это не SEO-боты, а direct-боты, т.е. гораздо более опасная для рекламодателя штука.
>>Для потокового процессора или для системы с локально	>>Для потокового процессора или для системы с локальной памятью оно программируется принципиально по-разному разница в том, что для 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 архитектур.
Тут коротким ответом не отделаешься. SGEMM - действительно,	Тут коротким ответом не отделаешься. SGEMM - действительно, при такой скорости памяти уже нет принципиальной разницы между блоками 4x4 (rapidmind) и блоками побольше. Ну так и задача не требует scatter и локальной памяти, можно в регистры распихать. Но возьмите любую непрямолинейную задачу. Гистограмму или сортировку. Для потокового процессора или для системы с локальной памятью оно программируется принципиально по-разному. И никакие автоматические средства не сменят алгоритм. Огромное количество вещей на CUDA просто пишется иначе - это именно другая архитектура и никуда не деться. Заметим, что у RapidMind, где подход близок к Brook, разный код умножения матриц для Cell и для GPU. На Cell блоки 4x8, на GPU - 4x4. К слову о RapidMind - я когда регистрировался, соглашался с лицензией. Сожалею, но выложить не могу. У них какие-то свои причины закрыть регистрацию
в том-то и прелесть подхода с runtime, что разбиение на блок	в том-то и прелесть подхода с runtime, что разбиение на блоки выбирается в момент исполнения и может адаптироваться под архитектуру. не надо даже перекомпилировать ничего. как я уже писал, по аналогии - на ассемблере всегда можно написать более быстрый код, в том числе за счет использования фич конкретного железа (scatter). но писать этот код очень сложно и он "привязан" к железу. в ваших тестах BLAS3 CUDA vs RapidMind видно, что производительность CUDA не намного выше RapidMind, зато последний вариант легко портируется на любую видеокарту. по поводу RapidMind. а не могли бы вы её выложить куда-нибудь,если у вас сохранилась? или может быть ссылка есть?
Да, если "не в теме", то будет трудно.	Да, если "не в теме", то будет трудно.
Автору статьи: у вас ужасный русский язык. Приходится по нес	Автору статьи: у вас ужасный русский язык. Приходится по нескольку раз перечитывать абзац, чтобы понять его суть. Количество неологизмов в вашем труде также весьма разочаровывает.
Ну чудес то не бывает. Вот банальное умножение матриц. На &q	Ну чудес то не бывает. Вот банальное умножение матриц. На "обычном GPU" надо делать блоками 4x4, а на cuda - 16x16 или 32x32. И никакой компилятор одно в другое не перепишет, чудес не бывает. Аналогично со scatter - в DX/GL его нет, а счастья может быть много. А RapidMind похоже с открытого сайта все убрал и регистрацию девелоперов прикрыл. Не знаю почему.
в Brook управление памятью происходит динамически. где в кон	в Brook управление памятью происходит динамически. где в конкретный момент находится поток пользователь не знает, это может быть CPU RAM, GPU RAM, GPU cache и т.д. runtime выделяет/перемещает данные по необходимости, где удобнее. еще вопрос по RapidMind, пытался скачать trial, но не нашел как это сделать на сайте. подскажите пожалуйста где именно.
Ну подождите. У CUDA есть local storage, у другого оборудова	Ну подождите. У CUDA есть local storage, у другого оборудования - нету. У CUDA можно писать в произвольный адрес памяти, у остальных - только поток (+-MRT). Это приводит к принципиально-разным алгоритмам, которые на уровне рантайма нельзя свести к одному представлению. Ну давайте представим себе хоть гистограмму что-ли (хе-хе, напишите это на потоке). В том что касается архитектуры, NVidia приложила в это место массу усилий, они собираются масштабировать путем увеличения числа SP (т.е. просто распараллеливать) и этот путь - хороший и правильный.
ну это вопрос runtime Brook, доступ может быть неявный. зато	ну это вопрос runtime Brook, доступ может быть неявный. зато у Brook есть много других плюсов, можно писать элегантные программы не заточенные под какую-либо конкретную архитектуру. я бы сравнил Brook с High-Level language для GPU (С++/STL), а CUDA - это C код со вставками ассемблера. под каждую новую архитектуру (чип) придется править код. все оптимизации приходится делать вручную, никаких generic алгоритмов. ИМХО серьезные программы писать очень сложно и поддерживать их потом еще сложнее.
Дорвейщики в очень большой степени местные, это правда.	Дорвейщики в очень большой степени местные, это правда.
Brook не дает доступа к shared memory и прочим фишкам CUDA.	Brook не дает доступа к shared memory и прочим фишкам CUDA. А это огромная разница во всем.
ИМХО CUDA хороша как библиотека функций (BLAS, FFT), но для	ИМХО CUDA хороша как библиотека функций (BLAS, FFT), но для программирования своих алгоритмов лучше использовать Brook.
Мне больше нравится статистика Google Trends по фарме в обще	Мне больше нравится статистика Google Trends по фарме в общем и по "buy phentermine online" в частности. Везде лидируют Россия\Украина\Белоруссия, с гигантским отрывом причём :) Дорвейщики как класс родом из Союза чтоли? :D
Мдя... Я в подписках тож смотрел... ((( Есть такая фича для	Мдя... Я в подписках тож смотрел... ((( Есть такая фича для платников, но это ж маразм...

Свежие комментарии

Pages