Забыли, что в память GPU ещё нужно скопировать данные, а потом скопировать обратно. 😉

Ну и файлики-то читать-писать только с CPU можно.

Это в каком году было?  jmp и goto на видюхах есть, поэтому if работает общая память там не хуже обычного x86.  Да конвейр сбраываетя дольше поэтому такая вещь будет тормозить. Да и частота не сильно утупает. У некоторых 2٫4 Ггц  Зато у компилятора парсинг хорошо параллелится. Так что основная часть ускорится. Да и оптимизацию на уровне регистров и машинных команд тоже можно распараллелить.  
Проблема в другом такой код компилятора становится абсолютно не поддерживаем.  Поэтому этим никто заниматься не будет. А следовательно всё будет тормозить.
Хотя вон для VHDL делают траспиляторы на GPU и оно быстрее чем на СPU раз в 10. Но это пожалуй исключение.

т.е. все-таки можно, но очень сложно?

Можно. Сложность оценить не представляется возможным так как никто и не пробовал. Буйных мало вот и нету вожаков. Думаю не намного cложнее чем под CPU, но алгоритмы будут кардинально другими.

> Зато у компилятора парсинг хорошо параллелится

Шта?

я вот только https://github.com/Co-dfns/Co-dfns видел. Смотрел доклад автора, он там рассказывает, как в него никто не верил, но он вот смог, нашёл какие-то алгоритмы для деревьев, основанные на массивах, и с ними всё быстро и удобно получается. Но полноценно понять и проверить его я не могу

С гранулярностью в один файл. Берешь 100 файлов и парсишь их параллельно

Кхе)

Если вдруг вспомните что за доклад, скиньте, пожалуйста

https://news.ycombinator.com/item?id=13797797

тут ссылка сверху на ютуб

Можно поискать на ютубе "aaron hsu". Там есть несколько видео с конференций. Какие-то конкретно про деревья

Так как у GPU отдельная память )

Там есть DMA

DMA к какой памяти?

Кстати, про GPU. Перечитывал давеча IXBT, много думал... Вот там заголовок "Пока Intel добиралась до 56 ядер, AMD уже начала готовить 128-ядерные процессоры с полугигабайтом кеш-памяти. Это будут новые CPU Epyc".

Это же практически GPU по количеству потоков. Причём, заметьте, доступная почти каждому. Если раньше такие огромные машины стоили по 50к вечнозелёных, и стояли в очень деньговместительных банках, то AMD даёт надежду всем и каждому. По моему опыту общения со старыми SPARC/POWER, нормально нагрузить их, используя все ядра и разделяемую память, сильно этим ускорив выполнение задачи, может только Make. Для других языков требуется жуткая квалификация и силы.

Вопрос - что думает великая компиляторная мысль по этому поводу?

У вас какой-то специфичный опыт :-) Для нагрузки такого сервера требуется веб-сервер, или БД, или трассировщик лучей. Компиляторы, в общем-то, тут не при  чем, если  только речь не идет о каком-то нишевом языке

А чё тут думать. Паралелить надо по функциям. Разбиваешь вводной текст на функции и далее и парсинг и кодо-генерацию для отдельных функций делаешь на отдельных ядрах.
Про разбиение тут три алгоритма который быстрее.
Либо вначале выясняем границы комментарии и строки. Либо поле сразу разбиваем на лова и  поле помечаем те что в троки вошли.
Либо работаем по схеме 4:2.

парсинг и итоговый кодген упираются в io обычно

а вот семантика и оптимизации параллелятся очень фигово