Здравствуйте, reductor, Вы писали:

R>Какое быстродействие.

Обычное.

R> для этого а) не нужно никакого анализа. б) это прописано в _стандартах_ некоторых языков.
R>как можно _оптимизацией_ называть то, что входит в стандарт?

Пофигу куда что входит. Для ФЯ эта оптимизация жизненно-важна, вот и додумался народ упомянуть о ней в стандарте. Попробуй найти ИЯ в котором такое же упоминание найдется.

R>в случае со scheme и haskell, например, это "уменьшение быстродействия" приведет к неработоспособному коду
R>вот и все.

С чего бы это? Если ты о линивости, то это несколько другая песня.

R>если мы делаем dead code elimination, loop unrolling и прочее — мы должны уметь _доказать_, что это не изменит результат вычислений.

+1

R>то есть мы должны сделать анализ и сопоставив его и спецификацию язяка доказать, что это ни на что не повляиет.

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

R>а то так можно назвать оптимизацией сам факт компиляции вместо интерпретации кода на месте — тоже ведь повышаем быстродействие.

Ненадо излишней философии. Мы говорим об оптимизациях в компиляторах. Ни один интерпретатор на вычислительных задачах и рядом не встанет с компилятором.

R>инлайнинг — тоже требует анализа того, что это сделать можно. потому что не каждая функция может быть заинлайнена.

Заинлайнина может быть любая функция. Другое дело, что иногда кроме этого нужно оставлять тело метода. Но это детали. Какое это отношение имеет к делу?

Ты утверждашь, что замена рекурсии итерацией не оптимизация. Почему же тогда это не делается почти во всех компиляторах ИЯ?

R>потому у окамла и плохо с этим, кстати.

У Окамла плохо не с этим. У него плохо с тем кто пишет бэкэнд компилятора. Хотя я бы назвал это даже не плохо, а так... "не супер". Все же он генерирует довольно приличный код. У Окамла есть куда больше идеологических проблем вроде ориентации на списки. Тут уже потрбеются алгоритмические оптимизации которые куда как сложнее в реализации.