Есть ли разница для компьютера: x**3 или x*x*x?

Question

[dbardakovv]

Всем доброго времени суток. Помню мой преподавать с алгоритмизации и программирования, проверяя мой код, сказал не использовать возведение в степень "pow ()" а просто умножать переменную саму на себя (дело было на C++). На вопрос почему он ответил что так эффективнее, но не объяснил почему. В js есть оператор "**", и мне стало интересно действительно ли так. Может кто-то знает правда ли это, и если да, то почему? Зарание спасибо.

Comments

[dollar]

Первое считается, как x**y, где y - любое число.
Второе считается, как x**y, где y - натуральное число.
Очевидно, что второе алгоритмически вычислять проще.

Но в теории, если компилятор умеет оптимизировать такие вещи (заменять x**3 на x*x*x на этапе компиляции), то нет разницы, как писать.

[Василий Банников]

А разве в C++ вообще есть такой оператор?

[dbardakovv]

Василий Банников, dollar, прошу прощения, я перепутал. Мне это просто стало интересно сейчас, когда начал учить js и перепутал с pow() плюсов. Но суть вопроса та же

[pfg21]

dbardakovv, посмотреть реализацию pow() в библиотеке :)
при равным прочих условиях, pow (x, 3) будет дольше работать чем просто x*x*x.
если только в компиляторе, как отмечено выше, нет оптимизации по превращению pow (x, 3) в x*x*x

[Василий Банников]

В C++ нет оператора ** (в смысле возведения в степень)

Так что возвести в куб можно только двумя способами - перемножением и функцией pow

[dbardakovv]

Спасибо
Я обновил вопрос, в начале я напутал немного.

[Василий Банников]

dbardakovv, в js же тоже нет оператора **

[Василий Банников]

pfg21, кстати чисто в теории pow(x, 3) и x*x*x дадут разные результаты, если работа идёт с числами с плавающей точкой

[pfg21]

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

[Adamos]

pfg21, цикл с перемножением для сокращения расходов должен предваряться возведением в степень, являющуюся ближайшей степенью двойки снизу. Так что разница все равно будет. Не на кубе, впрочем.

[pfg21]

Adamos, и один фиг какая оптимизация накручена для функции надо смотреть в исходниках библиотеки :)
я так... ткнул пальтцем в небо

Answer 1

[Армянское Радио]

Для таких вопросов есть специальный инструмент.

Препод прав.

При возведении в маленькую натуральную степень (2-30) компилятор может использовать векторные инструкции и получить результат очень быстро.

При использовании pow() происходит вызов специальной подпрограммы (что является относительно медленным делом), которая делает гораздо больше арифметических действий ( и работает только с числами с плавающей запятой, что потребует преобразования int->double )

Answer 2

[Tiriet]

x*x*x скорее всего будет транслирована в три умножения (в зависимости от флагов оптимизации и версии компилятора могут быть разные варианты, как именно по регистрам это все раскидано будет, но не суть). В любом случае, это относительно быстрые инструкции вещественного умножения (1 такт и латентность 3-4).
pow(x,y) обычно реализована exp(y*ln(x)), и транслирована она будет с использованием инструкций fyl2x (ln2(x)) и f2xm1 (2^^x -1). а вот инструкции логарифма и экспоненты- это оооочень медленные инструкции, у логарифма под 50 тактов на исполнение и латентность больше сотни (под 150), у экспоненты- тактов под десяток и латентность порядка 30 (понятно, что у разных архитектур- числовые значения разные, но порядок величин- такой). А если ваша pow вызывается редко (а она обычно редко вызывается относительно других вычислений)- то работать она будет мало того что долго по собственно тактам исполнения, так еще и со всеми возможными штрафами к производительности. для сравнения- fmul (вещественное умножение) имеет латентность 4 и выполняется за 1 операцию.