Начальник натолкнул на вот такой ста-аренький [url="http://ramlamyammambam.livejournal.com/44265.html"]кусочек ЖЖ-шечки[/url]. Само по себе это - не более чем зарисовка к практике с заведомо известным результатом. Скорее всего человек из любопытства "пощупал" разные архитектуры на один и тот же код. И вывод несколько... поспешный. Честно говоря, я был приятно удивлен, что GCC способен рассмотреть циклический сдвиг в том виде, в каком его приходится писать на C. И вместе с тем в том обсуждении есть [url="http://ramlamyammambam.livejournal.com/44265.html?thread=465385#t465385"]одна ниточка...[/url] С одной стороны результаты впечатляют: то, что другие делают за 6 и более команд, "Эльбрус" (который E3M), умудряется выполнить за 3. И вот тут начинаются "но".
"Но" первое. Компиляторы. Для "Эльбрус"'а использовался его "родной" компилятор. Неплохо посмотреть на то, что сделают с этим кодом хотя бы интеловский и сановский.
"Но" второе. На "Эльбрусе" приведенный цикл можно упхать даже не в 3, а в 2 команды. И по моим прикидкам без потери производительности. "Эльбрусовский" компилятор по каким-то непонятным мне причинам не любит определенный класс инструкций и в этом случае - зря.
"Но" третье. В любом случае "Эльбрус" проигрывает в размере кода (который в байтах).

По мне все это еще одно свидетельство двух вещей:

Компиляторы всегда оставляют место для "ручной" оптимизации. Их код никогда не оптимален. Да, он лучше того, что может написать на асме среднестатистический программист, но вот - лучший ли? - Нет, и думаю, никогда не будет. Пусть даже для конкретной платформы задача со временем и решается, но к сожалению/счастью развитие процессорных архитектур не стоит на месте. Компилятор - это просто машинка для генерации кучи исполняемого кода. Более-менее эффективного кода. С одной стороны компиляторы позволяют ПО активно развиваться, а с другой - позволяют программистам спокойно себе деградировать, занимаясь на разработкой эффективных программ, а быстрой разработкой программ. Но все счастливы. Поэтому все правильно )

Слабым местом VLIW-архитектур (архитектур с широким командным словом) всегда будет их сильная зависимость от компилятора. В этих архитектурах способность гарантированно одновременно исполнять заданный набор команд сочетается со сложностью машинной оптимизации потока команд. Пяток арифметико-логических устройств, каждое принимает на вход по два операнда (в среднем), выдает результат, который служит операндом парочки соседних АЛУ, что только что выработали новые операнды... Зависимости иногда получаются такие, что черти ноги ломают. Предполагается что за всем этим бардаком должен следить компилятор. Он должен грамотно и эффективно организовать бардак - и все будет чики-пики. Так думал даже Intel в начале работы над Itanium'ом. Все оказалось несколько сложнее. Значительно сложнее.

Код всегда будет идти позади аппаратуры, которая его исполняет. Код всегда будет что-то упускать, чего-то забывать про какие-то возможности, использовать аппаратные ресурсы неэффективно...
Реплика из нечаянно подслушанного разговора инженера и программиста. Инженер: "Это у вас есть свободные ресурсы для оптимизации, у нас ресурсов уже нет." Хочется, чтоб было иначе, чтоб человеческий разум (если он еще где-то есть) оказался разумнее кремния. А то и вправду настанет Матрица. Или уже настала.