> Эта проблема сильно преувеличена. Да, всего ничего - исторически все VLIW загибались по этой причине. А так все хорошо, прекрасная маркиза...
> Если выделить на это нормальные ресурсы, хотя бы
> команду из нескольких человек на полный рабочий день,
Почему-то с этим вышел FAIL даже у интела с итаником. Думаете Пилково и прочие Ростехнанопилы смогут лучше? Команда из нескольких человек на полный рабочий день будет пахать ДЕКАДУ до того как напишет с ноля компилер сколь-нибудь сравнимый с существующими. Эту декаду проц будет являться довольно бесполезным и неконкурентоспособным куском кремния, пригодным только на брелки для ключей. А если не писать компилер с ноля - получится "как обычно" - т.е. как-то код конечно генериться будет, но использованием плюсов архитектуры и оптимизацией и близко пахнуть не будет.
> то это вообще не проблема, за пару месяцев можно все неплохо оптимизировать.
Агащаз...
> Для примера, в драйвере видеокарт AMD r600 сделали ведь компилятор
> с оптимизациями для VLIW, причем вообще в свободное время.
Только вот
1) Оптимизатор не такой уж и оптимальный, пока выжимает около 75-80% от проприетарного драйвера...
2) Амдшники убили 2 года чтобы LLVM начал генерить просто технически-валидный поток команд для VLIW. И то сделано убер-костылем: то что нагенерил LLVM скармливается отдельной фазе которая фиксит поток команд с учетом взаимозависимостей. LLVM про это вообще "не алё" сам по себе. То что оптимальность такого кода ниже плинтуса - думаю понятно.
3) Посмотрите на OpenCL ядра. И как вам такая запись алгоритмов? Сильно похоже на "обычные", да? Нормально прогрузить то что у АМД можно только специфичными вычислениями, записанными специфичным образом. Тогда оно конечно жжот напалмом, но программирование этой штуки - знатный рокетсайнс :).
4) А вы не знаете почему AMD перешел на GCN? Поставив таки что-то типа аппаратного планировщика и что там еще, чтобы разгрузить компилер немного :).
> Что касается эльбруса - никто же не ставит главной целью сделать самый
> быстрый процессор, самый качественный компилятор, завоевать весь рынок, и т.д.
А цель "освоить бюджеты" смотрится как-то плоховато.
> даже если, предположим, производительность генерируемого кода была бы в два раза
> хуже теоретического максимума, это не значит что такой компилятор нельзя использовать
Это значит что компьютер с эльбрусом купят за налогоплательщиковское бабло, засунут в дальний угол, а все задачи по факту будет крутить вон тот 200-баксовый писюк с виндами из соседнего ларька. Который при санкциях разумеется превратится в тыкву, после чего ВНЕЗАПНО окажется что эльбруса никто даже включать не умеет...
> и улучшать по ходу дела.
Продукция эльбруса существует не первый год. Где улучшения?
> чем заменить импортную технику при минимальных затратах,
Судя по озвученным ценам эльбрусов - у некоторых очень своеобразные понятия о "минимальных затратах" :\.
> производительность и компилятор недотягивает - можно в крайнем случае и вручную
> оптимизировать.
Я видел только 1 раз за всю историю, когда человеки на это расперлись. Это называлось майнеры биткоинов. Когда вопрос в том что скорость счета напрямую приносит бабло - там да, люди "гибнут за металл", показывая чудеса оптимизации. Но в ваших задачах так ведь не будет...
