В Эльбрус запилили видеоядро

То есть вливы то делали (вспомнить хотя бы Transmeta), а вот компилятор только интел и осилил и никому не показал.

Компилировать для VLIW умеют еще как минимум GCC и LLVM. То, что у них получается не лучше, чем у Intel, кое на что намекает.

Ну и сейчас я тебе укажу что у него вполне нормальная целочисленная производительность, на что ты ответишь что маленькая частота и что она не наращивается, на что я отвечу что у итаника как то наращивалась (аж до 2700 доросла), на что ты ответишь что это максимум (хотя каких то долбаных 6 лет назад, 3ГГц у x86 был потолок и вот еле еле доросло до 4ех), на что я тебя попрошу показать мне кого нибудь из представителей суперскалярных (армов, спарков или мипсов, Power - не в счет) с частотами достигшими Intel или AMD.

Смотря что компилировать и как
Без конкретного примера трудно это обсуждать.

Ну и сейчас я тебе укажу что у него вполне нормальная целочисленная производительность

Указывай, я пока этого не вижу.
Расскажи мне, пожалуйста, как в опенофисе можно нарыть достаточно паралеллизма, чтобы забить все командное слово у влива, например.
Сейчас ты скажешь, что на вливе будет здорово матрички в спредшите множить, так?

Доктор, меня все игнорируют!

Смотря что компилировать и как

Ты говорил о VLIW, и я о VLIW.

Без конкретного примера трудно это обсуждать.

Да? Ну, обсуди Itanium.

фиксед

Открывать странички - это не вычисления.
Ты еще придумай «открытие контекстного меню» в широкую команду забивать.
Я честно не знаю как оно все в низу работает, но точно уверен что ты путаешь команды и тупое in-order исполнение, а современную OC с терминалом.

Я честно не знаю как оно все в низу работает

Может стоит узнать?

Ну как
printf("Hello World!")
-O0 main.c
наверно и не сильно отличается. Чему бы тут отличаться.

Узнать что именно? Как ядро работает?
Если в виде ассемблера представить, например то и открытие форматированного документа это очень гигантская по объему задача, чего бы ей широкую команду не забить? Не считая того что там ядро наверное еще свои сообщения куда нибудь пихает. Хрен знает в чем отличие от суперскаляра.

Смысл примерно такой. Есть у нас скажем кусок кода который только считает чиселки. Компилятор чудно распараллелил его в статике, расставил команды подкачки кода и данных и т.д. Этот кусок исполняется, все исполнительные устройства в АЛУ молотят, всё круто. Дальше пользователь нажимает на кнопочку или прерывание приходит или контекст надо переключить. И начинается веселье - нужно регистровый файл прочистить (который неслабых размеров), новый код подкачать, запустить обработчик прерывания и прочие такие вещи. В обработчике код редко когда можно распараллелить, обычно там каких-то тяжелых рассчётов нет. Поэтому в этом случае всё работает не шибко лучше чем обычный in-order. И частота 800. Если пользователь особо машину не дёргаети задачи в основном вычислительные то вроде ничего. А на интерактивных задачах - так себе.

Все равно не понимаю, вот в памяти функции (образно говорю) какие то висят, они на вход данные принимают (или не принимают). Вот пользователь нажал или документ открыл - запустился OPEN_DOCUMENT(*) в бинарном виде, с теми данными которые ему скормили. Все - оно там уже разбито на очередь команд, которые просто тупо по очереди исполняются, причем за одной коммандой может быть комманда из другого кода и все это вот так по очереди щелкается.
Откуда какой то динамический код берется нигде и никем явно не описанный - я не понимаю.

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

Эти события редки по сравнению со скоростью работы процессора. Проблема в том, что компилятор не распараллелил чудно - он распараллелил как мог.

Код-то описанный. Просто на него переключаться долго. Код лежит где-то в памяти. Когда компилятор знает какой код исполняться дальше, он может заранее подкачать его из памяти в кэш и быстренько обработать. Т.е. когда мы скажем перемножаем матрицы код который должен исполниться заранее известен. С некоторыми оговорками это будет работать даже если в коде есть ветвления. Но как только появляется некий элемент неопределёности - например нужно обработать события от пользователя - производительность будет просаживаться. Типичная задача обработки скажем прерывания - прочитать регистр из устройства (ждём пока устройство ответит), на основании значения бита в регистре вызвать функцию (подкачиваем код, исполняем), прочитать другой регистр и т.д. Распараллелить это нельзя в статике.

О качестве компилятора мне ничего не известно.

Точно ничего не известно, но можно предположить, что по качеству он недалеко ушел от ICC или GCC, а те не параллелили чудно. Плюс у e2k степень параллельности даже выше, чем у Itanium.

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

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

Если бы продавали по вменяемым ценам - я бы давно купил себе для разных тестовых дел.

+1