LINUX.ORG.RU

Сборка на GPU

 , , ,


0

1

Привет всем. Тут меня посетила странная мысль: можно же собрать программу из исходников в несколько потоков если у тебя многоядерный процессор. Но сколько там ядер? Ну 4, 8, 16, а на видеокартах их сотни, даже больше тысячи бывает, что если собирать софт с их помощью? Можно ли заставить make работать с видеокартой?

Я разрешаю.

anonymous ()

Можно ли заставить make работать с видеокартой?

Да, только вот есть нюанс. Представим что есть видеокарта с 4096 ядрами, где эти ядра делятся на 16 блоков по 256 ядер в каждом. Эти 256 ядер одновременно могут исполнять только одну инструкцию. Для графики это вообще не проблема, например у 1080p это 2млн пикселей и одновременная операция смешивания двух изображений ложится на эти ядра просто идеально. Но вот компиляция это уже другой тип операции, тут на всех ядрах должен разный код выполняться из за кучи ветвлений что ставит на нет все преимущества этих 4096 ядер.

V1KT0P ★★ ()

Платиновые треды.

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

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

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

В процессорах это называют вектор столько-то бит.

Не встречал такое описание, я так понял что в сущности это множество alu которые шарят один стек и на которых один instruction pointer.

Aber ★★★ ()

Нет. Нельзя ни make ни что-либо еще. Просто архитектура не годится для этого.

Все помнят новость «nVidia заставит работать Linux на GPU непосредственно». Реализации мы так и не дождались.

I-Love-Microsoft ★★★★★ ()
Ответ на: комментарий от Aber

Не встречал такое описание

В CUDA это называют thread, в OpenCL это work item. Но по своей сути это действительно походит на SIMD, только вот для маркетинга это не звучит. Так на сотню «ядер» один кеш инструкций, один декодер.
Вот Intel сделали Xeon Phi там удалось увеличить количество настоящих ядер до 72 штук, правда работающих на 1.5Ghz. Но зато по 4 потока на ядро, что хорошо может «скрывать» задержку чтения из памяти.

V1KT0P ★★ ()

А зачем вообще нужен процессор, когда есть видимокарта, на которой теперь модно делать вообще всё? Напоминает блокчейн, на котором теперь тоже модно всё делать.

Unicode4all ★★★★★ ()
Ответ на: комментарий от I-Love-Microsoft

Нет. Нельзя ни make ни что-либо еще. Просто архитектура не годится для этого.

С чего это нельзя? Чтение/запись памяти есть, логические/арифметические операции есть, условные переходы есть. Что еще нужно?
Только вот тот-же 1080ti для таких случаев будет 28 ядерным In-Order процессором с частотой 1.5GHz и без предсказателя переходов, да еще и с огромными задержками доступа к памяти.

V1KT0P ★★ ()

можно. но нужна машина времени. сгонять, грохнуть парочку засранцев, которые впарили человечеству существующую сегодня архитектуру. тогда у тебя было бы просто дофиглион ядер в одной фиговине, без разделения на все эти гпу\цпу. и память не была бы однопоточным ботлнеком. из бонусов — отсутствие пары уродливых языков погромирования и уменее в мультитред ещё в 70-х.
из минусов — как раз в 70-х было начало AI разработок, а людишки тогда были тупые. им дай такую йобу — сделали бы скайнету, к ванге не ходи.

system-root ★★★★ ()
Ответ на: комментарий от V1KT0P

Я исхожу из практических соображений. Инфраструктуры нет, даже если задумать такой проект самому с нуля. И какой смысл в make, если там нужен GCC или нечто вроде. Так то может и можно было бы. Но я не уверен что архитектура это позволяет.

Неужели GPU позволит на одном ядре своем выполнить произвольную последовательность команд любой длины, да еще обращаться ко всей имеющейся памяти? Если да, то будет это медленно.

I-Love-Microsoft ★★★★★ ()
Ответ на: комментарий от I-Love-Microsoft

Я исхожу из практических соображений.

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

V1KT0P ★★ ()

Нет. Вычисление на GPU - это, когда много тупого.

Компиляция под это не подходит

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

Да вроде собирались оффлоадить сборку на видеокарту, даже в гцц. Не понимаю что регистрантам в треде не нравится, это видимо именно то, чего хочет ОП.

Вот только видеокарты хорошо лишь матрицы складывают, больше они ни на что не годятся.

https://gcc.gnu.org/wiki/OpenACC https://gcc.gnu.org/wiki/Offloading

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

У тебя сборка на проце для видеокарты.

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

Получается, это только аналог openmp и даже hsa нас не спасёт? Амд вроде тем и занимались, не знаю к чему пришли.

anonymous ()

Что только не придумают любители AMD FX.

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

писать больше копипасты в надежде на то, что идентичный копи-код будет параллельно обрабатываться на 256 ядрах

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

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

anonymous ()

Можно, но как сказали выше, сначала добудь машину времени. Потом отправляйся в 2010й и предотвращай закрытие проэкта Intel Larrabee. По слухам, у них было ~80 x86 ядер на которых крутилась фряха, с программной реализацией графических API. Думаю компилять на них тоже можно было.

klokik ()

ещё можно в видеопамять положить исходники и их собирать любым компилятором, вот тебе сборка на gpu

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

Его не пытались назвать GPU. Варочем ноги у Phi растут как раз из проэкта Larrabee.

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