LINUX.ORG.RU

GCC, nvidia, cuda


0

0

есть ли вариант GCC, запускаемый на видеокарте? Чтобы компилировать не в 2-3 потока, а во столько, сколько видеокарта может.

★★★★★

нет и навряд ли будет.

Sylvia ★★★★★
()

Неоднократно обсуждалось, что для чего-либо не сводящегося к перемножению матриц GPU подходит плохо.

KblCb ★★★★★
()

Там совсем не такие 'потоки' как в CPU. Даже если кто-то и сделает proof-of-concept канпелятор на видеокарте, то он будет просто жутко проигрывать обычному.

kranky ★★★★★
()
Ответ на: комментарий от KblCb

> для чего-либо не сводящегося к перемножению матриц GPU подходит плохо

Оно подходит для чего угодно, хорошо разбивающегося на независимые подзадачи. Есть какие-то фундаментальные трудности, не позволяющие разбить код при компиляции на более-менее независимые куски, не забыв позаботиться о подходящей стуктуре для хранения символов? Конечно, такого эффекта, как при перемножении матриц, не получишь, но, тем не менее, GPU имеет N-ое количество мультипроцессоров, у каждого из которых своя локальная память и кэш. Посему в сферически идеальном случае выигрыш в N раз получить можно было бы. Другой вопрос, что это совершенно неимоверные, вряд ли оправданные, трудозатраты.

fang
()
Ответ на: комментарий от kranky

> то он будет просто жутко проигрывать обычному

Ты провёл полноценный анализ с построением мат. модели или просто так ляпнул?

fang
()
Ответ на: комментарий от fang

А что, компилирование у нас уже научились эффективно распараллеливать? Не надо путать мультипоточное и параллельное программирование.

И все исходники и линкуемые либы (тысячи их) ты будешь сразу в память видюхи загонять или постоянно гонять туда-обратно?

kranky ★★★★★
()
Ответ на: комментарий от kranky

> А что, компилирование у нас уже научились эффективно распараллеливать?

Нетривиальная задача, да.

Не надо путать мультипоточное и параллельное программирование


Никто и не путает

И все исходники и линкуемые либы (тысячи их) ты будешь сразу в память видюхи загонять или постоянно гонять туда-обратно?


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

fang
()
Ответ на: комментарий от fang

И кстати да, на GPU поддерживается 2 разных модели параллелизма: multi data и multi task. Во втором случае, это, по сути, и будет то, что ты обзываешь многопоточностью (хотя потоки вовсе не обязаны выполнять разные задачи).

fang
()
Ответ на: комментарий от fang

А вообще, я наврал: multi task модель не прокатит, потому что синхронизацию организовать не получится.

fang
()

У GPU нет множества фишек CPU

Wikipedia:

  • CUDA uses a recursion-free, function-pointer-free subset of the C language, plus some simple extensions. However, a single process must run spread across multiple disjoint memory spaces, unlike other C language runtime environments.
  • Threads should be running in groups of at least 32 for best performance, with total number of threads numbering in the thousands. Branches in the program code do not impact performance significantly, provided that each of 32 threads takes the same execution path; the SIMD execution model becomes a significant limitation for any inherently divergent task (e.g. traversing a space partitioning data structure during raytracing).
Kosyak ★★★★
()

> вариант GCC, запускаемый на видеокарте

Простите, но это полнейшая чушь. Нвидия дает свой sdk для этого, там все утилиты, расширенный язык С и т.п. Заявлена кроссплатформенность. Знаю и вдел, что на масдае работает. На линуксе не видел.

bk_ ★★
()
Ответ на: комментарий от fang

> Гигабайта памяти, имеющегося на борту, думаешь, таки не хватит для того, чтобы это всё туда загнать?

У меня при компиляции некоторых шаблонов на C++ компилятор съедал по 700Мб ОЗУ.

SSN
()
Ответ на: комментарий от fang

> Оно подходит для чего угодно, хорошо разбивающегося на независимые подзадачи.

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

frey ★★
()
Ответ на: комментарий от frey

> При чем здесь подзадачи, как раз плевать на подзадачи, главное, чтобы данные можно было разбить.

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

Почитай про SIMT на досуге


Ты бы для начала обозначение SIMD научился писать правильно, что ли. После того, как научишься, почитай про архитектуру GPU: он имеет матричную структуру, состоящую из M мультипроцессоров по N ядер в каждом. Все ядра в мультипроцессоре выполняют одну и ту же программу (но не инструкцию). А SIMD - он уже идёт на уровне ядра. Причём ядра в нвидиевских GPU вообще _скалярные_.

fang
()
Ответ на: комментарий от fang

SIMT == Single Instruction Multiple Threads, т.е. одновременно на всех процессорах выполняются одна и та же инструкция. Едва ли возможно реализовать компиляцию программ на SIMT архитектуре, imho

fads ★★
()
Ответ на: комментарий от SSN

заметьте , что на 1 поток 700Мб, иногда кстати бывает и больше

типичные С++ исходники - 100-300 Мб на 1 поток, так что гигабайта памяти хватит только на 3-4 потока

Sylvia ★★★★★
()
Ответ на: комментарий от fads

> SIMT == Single Instruction Multiple Threads

Да, уже понял что это за обозначение. Не знакома была сия аббревиатура.

т.е. одновременно на всех процессорах выполняются одна и та же инструкция


Там не совсем так. На самом деле, ядра могут испонять разные инструкции в рамках одной программы, но при этом иметь неявные барьеры в таких местах, как условные ветви и циклы (vendor specific). А мультипроцессоры могут и разные программы выполнять, но без возможности синхронизации. По крайней мере, OpenCL позволяет описанные мной возможности использовать, за другие интерфейсы не поручусь, не в курсе.

Едва ли возможно реализовать компиляцию программ на SIMT архитектуре, imho


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

fang
()
Ответ на: комментарий от fang

> На самом деле, ядра могут испонять разные инструкции в рамках одной программы, но при этом иметь неявные барьеры в таких местах, как условные ветви и циклы (vendor specific).

Да могут, в результате вместо 32 тредов выполняется один. %)

frey ★★
()
Ответ на: комментарий от fang

>Оно подходит для чего угодно, хорошо разбивающегося на независимые подзадачи

Авторитеты такие авторитеты. Дело не далеко не только в разпараллеливании но и на линейность программы. GPU ОЧЕНЬ не любят ветвления, в шейдерах каждый if считают.

theos ★★★
()
Ответ на: комментарий от fang

При компиляции буста один поток gcc откушиывает до 1 Гб.

у нас при компиляции mdc до 700mb

namezys ★★★★
()
Ответ на: комментарий от theos

Спасибо, кэп. Также вы долны быть осведомлены, что и циклы они не очень любят. Но речь шла вовсе не об этом.

fang
()
Ответ на: комментарий от fang

> Также вы долны быть осведомлены, что и циклы они не очень любят

Цикл = ИФ + goto.

Спасибо, кэп.

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

theos ★★★
()
Ответ на: комментарий от frey

> Да могут, в результате вместо 32 тредов выполняется один. %)

В зависимости от того, как они распределяться между условными ветками. Может и последовательно по 16 выполняться же.

fang
()
Ответ на: комментарий от theos

Да, согласен. Изначально указанные мной условия недостаточны.

fang
()

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

А то скоро уже просьбы чай в несколько потоков на видеокарте кипятить будут раздаватся.

Капча: jaguars this

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.