GCC + CUDA

Чую «нинужно»

Как будто это не так...

Представьте как возрастёт сборка gentoo?

Затормозится.

«нивзлитит»

Да. Сам догадаешься, почему?

Представьте боевой динозавр ниндзя. Ниндзя. Динозавр. Боевая ярость динозавра и скрытность ниндзя. Круто же?

Сначала разберись как работает куда, разберись как устроен и работает gcc. А потом оцени какие операции и как ты будешь оффлоадить на куду и сколько времени на реализацию этого тебе потребуется.

«нивзлитит»

Да. Сам догадаешься, почему?

Эмммм.... Нет. Почему?

Да нет, я не хочу разбираться. Готовое решение - вот мой выбор =)

Всё же прирость производительности должен быть...

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

у GPU крайне малый кэш, ветвления убивают скорость наглухо, сборка не сможет в параллелизацию.

GPU - это SIMD. Когда нужно одну операцию сделать над кучей данных. А когда данных много и операции разные - GPU будет лишь хорошо греться с околонулевым КПД.

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

Если так, то значит реально «нинужно» )

Будет медленнее

Да нет, я не хочу разбираться. Готовое решение - вот мой выбор =)

Тогда не создавай тупых тредов, не разобравшись в предмете.

Всё же прирость производительности должен быть...

Ты не имеешь знаний чтобы что-то прогнозировать.

Что нужно - так это использовать GPU через OpenCL.
Но программы, которые так умеют, можно по пальцам пересчитать (x264, imagemagick из десктопных)

Тогда не создавай тупых тредов

Дяденька, я вам грубил? Проходите мимо молодой человек.

Ты не имеешь знаний чтобы что-то прогнозировать.

А это мне решать ;)

Эмммм.... Нет. Почему?

Уточнений можно попросить у Eddy_Em, а я потеоретизирую с дивана.

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

Разбиение на токены на GPU не вынести, т.к. процедура выделения очередного токена заканчивается после чтения произвольного числа символов. Избежать ветвлений в данном случае можно с помощью конечных автоматов (DFA).

Парсинг на GPU не вынести, т.к. опять узлы AST разные и процесс сборки AST ветвится постоянно. Избежать ветвлений можно с помощью DFA, но он так же заканчивает работу в произвольный момент.

Семантические проверки на GPU не вынести, т.к. даже обход узлов AST постоянно ветвится. И я пока не слышал, чтобы семантические проверки можно было реализовать без ветвлений.

Можно попытаться сам gcc собрать с profile-guided optimization, тогда, возможно, он сможет сам для себя предсказать наиболее вероятные ветви выполнения и не будет тормозить на ложных предсказаниях.

Вообще для ускорения работы gcc.

Что именно ты собрался в gcc ускорять?

Я не доконца понимаю этот процесс, точнее вообще его не понимаю.

Именно так.

Написал тут, вдруг есть такое, или кто нибудь слышал.

Ну, тех, кто разбирается ты уже послал идти мимо. Ты действительно думаешь, что ценность и валидность информации зависит от степени расшаркивания ножкой?

Представьте как возрастёт сборка gentoo?

Представьте, как возрастет ваш русский язык, если вы перестанете постить тупняк на ЛОРе.

Да, да. Перестаньте постить тупняковые комменты и пишите по делу. Тогда и *люди потянутся*. А то все крики ШГ да УГ, и мало конструктивных ответов.

Раз в некоторый промежуток времени на ЛОРе возникает одна и та же тема: «Парни, смотрите, чего придумал: предлагаю конпелять на видюхе!».

Ты конечно не смотрел http://en.wikipedia.org/wiki/The_Terrible_Thunderlizards ? :)

Круто же?

Боян же.

невидия обходит. я патент смотрел, т.к. пилим с гуфами свой GPU.

у них раздаются не команды а ссылки на команды. технически можно разветвиться поменяв номер группы на stream processor.

Где там парни, смотрите чё я придумал? Если вчитаться «Хотелось бы услышать Ваше мнение». По крайней мере по этому треду сразу увидел, кто агрессивный, а кто адекватный и почерпнул нужные мне знания от умных людей, за что им кстати спасибо.

Нужно уходить от неудачной x86, да и от CUDA тоже уйдем, даже для числодробилок, на ARMv8, и возможно на ARMv8 можно будет поднять скорость сборки системы, которой еще предстоит появиться (быть написанной, но не на Си, и уж тем более не на подобных C++, а на языке ФП, к примеру на Haskell).

Да нет, я не хочу разбираться.

Я за бан.

Ничего не получится. SIMD фактически негде применить в GCC.

GPGPU так и разшифрофывается - General-purpose Graphic Processing Unit. В теории можно решать почти любую вычислительную задачу, но т.к. это SIMD, то будет какой-то профит в сравнении с CPU только в случае, если задача отлично распараллеливается на сотни потоков и не использует (либо минимально использует) ветвления.

x86 - конечно, неудачная, но процессоров общего назначения с аналогичной производительностью и такой же (или ниже) стоимостью, пока нет.

x86 - конечно, неудачная, но процессоров общего назначения с аналогичной производительностью и такой же (или ниже) стоимостью, пока нет.

Что самое гадкое, нет даже не-фатально проигрывающего. Ладно просто медленнее - при должном фанатизме пережить можно. А так все мечты пофапать на не-x86 систему и при этом не испытывать неудобств с тормозами отменяются.

Что самое гадкое, нет даже не-фатально проигрывающего.

А как же ынтырпрайзные паверы и спарки? Не десктоп, но фапать-то на них это не должно мешать...

Не десктоп, но фапать-то на них это не должно мешать...

Я раньше бредил подобным, потом на работе пожил неделю рядом со стопкой рэковых HP. Больше не хочу.

x86 - конечно, неудачная

Таки чем она неудачная кроме немодности? На асме кодил в юности, очень легко и просто, в сочетании с ROM BIOS и прерываниями DOS практически полноценный ЯВУ получался.

x86 - это страшное нагромождение костылей, некоторые из которых тянутся еще со времен 8086:

1) Реальный режим - уже никому нафиг не нужен, но есть, и нельзя просто так взять и выпилить, ибо BIOS (UEFI больше этого не требует => может, в ближайшие лет 10 и выпилят).

2) Защищенный режим изначально был 16-битным => ввели селекторы и всё, с ними связанное. Естественно, с расчетом только на 16-бит. Когда придумали 32-битные процессоры, пришлось расширять все это костылями (см. формат дескриптора для 386 - эталонный пример костылей и подпорок). Но всё то, что наворотили в 286, оказалось по бОльшей части ненужным, ибо все стали использовать нововведенную страничную адресацию.

3) В результате введения SSE2 имеем два набора операций для работы с дробными числами.

4) В результате желания расширить возможности по использованию памяти придумали еще один костыль - PAE.

5) Введение большого количества расширений набора команд привело к тому, что пришлось пилить костыли, чтобы запилить еще больше команд (VEX).

6) Сложность набора команд неизбежно ведет к багам.

А потом пришли 64 бита... В результате имеем огромную исторически сформированную свалку того, что сейчас уже никому нафиг не нужно, но совместимость тянуть приходится, ибо любой современный процессор должен быть способен запустить любую программу, созданную за более 30 лет существования этой архитектуры. А это всё транзисторы. А транзисторы нельзя уменьшать безгранично...

Да и RISC, как по мне, более труЪ (процессоры гораздо более простые должны получаться). Тем более, что, AFAIK, в интеллах и AMD используется гибридное решение - инструкции CISC преобразовываются в RISC и затем исполняются.

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

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

И вот, кстати, что-нибудь слышно про CUDA+транскодинг в Asterisk? Спрашиваю интереса для, не думаю, что если кто-то это и пилит, то ближайшие лет 5 оно вообще будет пригодно для использования.

Хотя, сам спросил, сам ответил:

In attempting this project, the following information was learned:

- Memory copy overhead and latency.

CUDA recommends that memory buffers coming from the application be transfered to the GPU in a staged approach to maximize the parallel activity of the GPU. While this is a perfectly reasonable recommendation, it introduces additional latency in our real-time processing environment. It is important to remember that these latencies are a trade-off: if the algorithm has a marked improvement in execution time which offsets the introduced memory latency, then it is completely reasonable to go this route. This would be perfectly acceptable for video transcoding, because of the larger amount of data to process with possibility of more complex algorithms. This is not the case for audio transcoding.

© http://lists.digium.com/pipermail/asterisk-dev/2009-January/035946.html

Т.е. даже объём данных в аудиопотоке недостаточно велик для нормальной загрузки GPU отдельным куском этих данных и выигрыша нет. Ну что же, для транскодинга, значит, выгоднее использовать какие-нибудь блейды многопроцессорные и кучу VoIP-серверов.

Транскодинг в Asterisk будет на ARMv8 это если про ближайшие годы говорить.

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