Рекурсия VS Циклы

[Kostia]

Машинное слово, почему нет.

Нет смысла в степенях > 64 при текущем выходном параметре. Хотя хз. как это на производительность влияет.

Полагаю, что из-за отсутствия ветвления в аргументах. Но это в нерекурсивный вызов компилятор не преобразует заведомо.

Да, это очевидно что не преобразуется, но и предыдущий тоже не преобразовывается =( судя по всему

[s-andriano]

Сообщение от Kostia

и компилятор мог бы допереть до этого и сделать очень мощную оптимизацию

"Допереть" - это не задача компилятора, это задача программиста.
Разные алгоритмы обладают разными характеристиками: ресурсоемкость в вычислениях в целых числах, ресурсоемкость в вычислениях с плавающей точкой, требования к памяти, требуемая глубина стека, баланс между операциями условного перехода и "линейным" кодом...
И в каждом случае для конкретных условий применения, о которых компилятор не имеет никакого понятия, выбор должен оставаться за программистом.

Глупо полагать, что если написать код кое как, компилятор потом "все равно все оптимизирует".

[Kostia]

Глупо полагать, что если написать код кое как, компилятор потом "все равно все оптимизирует".

Не кое как, а в так сказать "нормальной" форме.

"Допереть" - это не задача компилятора, это задача программиста.

Именно его задача, моя задача только явно указать ему места(написав код в соответствующей форме), которые можно оптимизировать и распараллелить, а не говорить ему как это делать.

Разные алгоритмы обладают разными характеристиками: ресурсоемкость в вычислениях в целых числах, ресурсоемкость в вычислениях с плавающей точкой, требования к памяти, требуемая глубина стека, баланс между операциями условного перехода и "линейным" кодом...

Алгоритмы тут совершенно не причем:

x = a + b;
y = x*2

и

x = a + b
y = (a+b)*2

Далеко не одно и тоже! В первом случае все будет выполняться последовательно, т.к. y зависит от x, во втором случае их можно выполнить параллельно. Пример высосан из пальца, но в целом все как-то так и подобные вещи компилятор должен сам распознавать и предпринимать соответствующие действия, вместо многословных методов распаривания.
И если бы процессоры не занимались оптимизацией команд которые им следует выполнять, то вообще труба дело. А так он сам разбирается что можно выполнить в разных вычислительных блоках, предсказывает переходы в памяти и заранее запрашивает предполагаемые данные у оперативки, пока сам выполняет вычисления. Из оперативки достает 64 байта и кладет их в кэш всегда(процессоры intel), грех этим не воспользоваться. И если есть возможность скомпоновать комманды таким образом, чтобы они были выполнены на процессоре в разных блоках, то этим нужно пользоваться, но гораздо лучше, если бы этим еще занимался и компилятор!

[Utkin]

x = a + b;
y = x*2

и

x = a + b
y = (a+b)*2

Далеко не одно и тоже! В первом случае все будет выполняться последовательно, т.к. y зависит от x, во втором случае их можно выполнить параллельно. Пример высосан из пальца, но в целом все как-то так и подобные вещи компилятор должен сам распознавать и предпринимать соответствующие действия, вместо многословных методов распаривания.

В Дельфи есть такая оптимизация. Именно для данного примера переменная х использоваться не будет.
В функциональных языках это часто (традиционно) реализовано еще символически. То есть в первый проход
x = a + b;
y = x*2
будет заменено на y = (a+b)*2 на уровне токенов, еще до оптимизаций команд процессора. Это есть например в ocaml.

[s-andriano]

Сообщение от Kostia

Далеко не одно и тоже! В первом случае все будет выполняться последовательно, т.к. y зависит от x, во втором случае их можно выполнить параллельно. Пример высосан из пальца, но в целом все как-то так и подобные вещи компилятор должен сам распознавать и предпринимать соответствующие действия, вместо многословных методов распаривания.

Т.е. Вы считаете, что 3 операции + накладные расходя на организацию "распаривания" и синхронизацию - оптимальнее?
Еще можно о чем-то говорить, если есть уверенность, что у нас всегда присутствуют свободные от работы процессоры/ядра (и то не в данном примере, но будем считать, что данный пример - лишь иллюстрация, а не реальный код).
А если у нас всего одно ядро?
Либо просто процессор загружен другой работой, и для него актуальна экономия именно процессорного времени, а не астрономического?

Еще раз: это не дело компилятора, распараллеливать или нет - должен решать программист.

[Kostia]

А если у нас всего одно ядро?

Даже одно ядро может выполнять несколько команд одновременно, т.е. может быть несколько функциональных блоков, выполняющих одни и те же команды.

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

Так называемое Фон-Неймановское горлышко, проблема архитектуры, с которой приходится мириться, увы.

Т.е. Вы считаете, что 3 операции + накладные расходя на организацию "распаривания" и синхронизацию - оптимальнее?

Никакой тут синхронизации и пр. просто будут выполнены параллельно в 2х функциональных блоках(источник: Оптимизация ПО Сборник рецептов. Intel Press).

организацию "распаривания" и синхронизацию - оптимальнее?

Проблема императивных языков

[s-andriano]

Сообщение от Kostia

Даже одно ядро может выполнять несколько команд одновременно, т.е. может быть несколько функциональных блоков, выполняющих одни и те же команды.

И что с того?
Все современные суперскалярные процессоры именно так и делают.
Но согласно программной модели, тем не менее, команды выполняются последовательно.

Никакой тут синхронизации и пр. просто будут выполнены параллельно в 2х функциональных блоках

Синхронизация как раз есть. Вплоть до сброса конвейера.
Но при чем здесь компилятор, который работает именно с программной моделью?

[Kostia]

Синхронизация как раз есть. Вплоть до сброса конвейера.

Я имел ввиду синхронизацию касательно побочных эффектов функций.

Но при чем здесь компилятор, который работает именно с программной моделью?

На втором курсе мы писали простенький транслятор обычных арифметических выражений на псевдоассемблер. Нужно было полученный код после трансляции оптимизировать, в последствии чего он сокращался раза в три, а то и больше. Было минимизировано кол-во операций работы с памятью и объем памяти необходимый для хранения промежуточных результатов, удалены бессмысленные команды типа x + 0, x * 1, -1 + 1.
Вопрос, кто же по вашему должен заниматься подобной оптимизацией? Кодер?