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