Есть ли среди нас Cuda девелоперы!

[lugal]

Помойму этого же китаййа и был...
Для новичков которые куда референс не осилили может он и полезен, но чего то большего там нет
Лучше поисктаь статьи Волкова на эту тему. ТАм есть что почитать.

 

[niello]

Помойму этого же китаййа и был...

Нет, универ Иллинойса.
Да, курс для новичков, но можно много чего интересного для себя найти (в последней части есть обзор других технологий).
+ курс не только лекции, а и форум.

 

[lugal]

в последней части есть обзор других технологий.

Опен ЦЛ?
Она ж страшная.

 

[niello]

Да, и OpenCL (ничего он и не страшный) и MPI и С++AMP и OpenACC. Но да, в большей части поверхностно.

 

[lugal]

Да, и OpenCL (ничего он и не страшный) и MPI и С++AMP и OpenACC. Но да, в большей части поверхностно.

OpenCl по сравнению с кудой как раз страшный
MPI - это кластерные вычисления. AMP и ACC - по сути обертки.
Учитывая тот факт чот узким местом Куды есть как раз трансфер данных - не думаю что это очень эфективные решения.

 

[ksuhak]

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

 

[niello]

OpenCl по сравнению с кудой как раз страшный
MPI - это кластерные вычисления. AMP и ACC - по сути обертки.
Учитывая тот факт чот узким местом Куды есть как раз трансфер данных - не думаю что это очень эфективные решения.

Да, поэтому курс и так и называется как называется, а не только GPGPU.

 

[lugal]

Да, поэтому курс и так и называется как называется, а не только GPGPU.

Ну основная проблема гетерогенных вычислений с которой столкнулся я - трансфер данных между вычислительными блоками, что не позволяет эжфктивно использовать ЖПУ для рапид акселерации - типа вынести BLAS и FFT на GPU.
BLAS становится более эфективных на достаточно больших объемах данных, а вот FFT у меня проигрывало всегда (На хосте был и7 (ну и МКЛ соответствено), и Тесла К2).
Посему приходилось перегонять вычисления сразу блоками, что так же не всегда эффективно так как немало кусков, которые крайне сложно либо вообще не возможно, распаралелить.
Так что я жду акселератор от интела, есть надежда что там все будет несколько быстрее.

 

[Anonymous99]

Для тех немного окпался в дизасмах, а также оптимизировал код на ассемблере. Плюс мог сталкиваться с VLIW архитектурой, например, процессоры TI320. Либо же просто педалил шейдеры, занимался графикой. Ну а также кто использовал GPU для ускорения вычеслений черз костыли. Тому CUDА кажется просто еще одним языком программирования для шейдеров. Уж больно пахнет Cg,GLSL, HLSL.

Ерунда. Во времена квейков и думов, был свой язык QuakeC. Написанный Кармаком от нечего делать, просто ради модулей наподобии DLL. Такс, приятная мелочь, бонус к игре.
Ну а если не можете разобраться. Так может тестировщиком идти работать? Или верстальщиком?
Судя по тем тупым вопросам, которые здесь звучат "А нафиг оно надо?".
Везде где есть два элемента - это массив данных, и однотипная обработка, используются технологии распарралеливания.
Книга валяется по куде. Я покупал просто потому что, хотел книгу по внутренностям видеокарт. Ну чтоб почитать на досуге или в туалете.
Но нашел это.
CUDA не очень классно. Слишком много всякого "for nVidia".

Для вас куда не представляет интереса, ввиду того, что физикой вы не заниметесь, серьезные работы, где нужна вся мощь у вас нет. На куда делают графику, вроде трассировки лучей. В качестве работы в Харькове не советовал бы начинать с этого. Ибо не шибко популярная, и слишком узкоспециализированная. Зависит от nVidia. Вот OpenCL стоило поучить, разобраться. Исходники скачать.

 

[lugal]

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

В теории все всегда звучит просто НА практике не очень Так как реальные алгоритмы далеко не полностью поддаются эфективному распаралеливанию, а при вычислених в слабопаралельной или классческой формах сами начинают становиться узким местом, по сравнению с ЦПУ. И возникает задача балнсировки.

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

Куда это не только физика. Реальные серверные решения с достаточно большим объемом вычеслений и с откликом в реальном времени используют ее достаточно эфективно.

Ибо не шибко популярная, и слишком узкоспециализированная. Зависит от nVidia. Вот OpenCL стоило поучить, разобраться. Исходники скачать.

Да, зависит от nVidia, но при этом представляет широкий набор инструментов (как либ так и плагинов разработки), очень С подобна, которые значительно ускоряют процесс. И, как показывает практика, подобные решения весьма востребованы на рынке, и зачастую выигрывают у более производительных с худшей поддержкой.

 

[Deamon]

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

После того, как я немного поработал оптимизатором С кода на VLIW архитектуру, мне академическая теория параллелизации кажется несколько оторванным от жизни материалом.

В обратоке звука многие алгоритмы поддаются параллелизации, даже если с первого взгляда, что из-за зависимости между данными в цикле параллелизация невозможна. Обратная сторона такой оптимизации - придется гонять большие объемы промежуточных данных с общей памяти на видеопамять и обратно.

Ну а также кто использовал GPU для ускорения вычеслений черз костыли. Тому CUDА кажется просто еще одним языком программирования для шейдеров. Уж больно пахнет Cg,GLSL, HLSL

Сама идея использовать GPU для общих вычислений появилась после того, как производители видеокарт посмотрели на ТО НЕЧТО, что они напроектировали, и поняли, что это, по сути, вычислитель с большим количеством однотипных вычислительных элементов. Когда появились шейдеры, допилить все это под использование для general computations было делом техники.

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

 

[lugal]

В обратоке звука многие алгоритмы поддаются параллелизации, даже если с первого взгляда, что из-за зависимости между данными в цикле параллелизация невозможна. Обратная сторона такой оптимизации - придется гонять большие объемы промежуточных данных с общей памяти на видеопамять и обратно.

Вот я о том и говрю, например AGC на базе нелинейного фильтра параллезировать так и не удалось.
МНогокональный IIR фильтр - удалось на с бубном. А любое такое место это перегон данных по шине, который нередко съедает результаты оптимизации и парралелизации доброго куска кода.

 

[novako]

Просто интересен спектр задач.

видиоплейр например KM Player корейский использует куду для декодирования видео. скажем там без куды слайд шоу, с кудой смотрится без проблем

мне вообще больше нравится Xeon Pi в нем много ядер х86, а не как в GeForce не потяно что.

так как комп CUDу не тянет

странно, что не тянет, надо всеголишь GeForce Gt 8ххх или выше, у меня был 8400 уже с кудой и стоил что то окло 350грн.