Быстрее ли умножать низкие числа в C/C++ (в отличие от больших чисел)?

Для встроенных типов по крайней мере до размера слова архитектуры (например, 64-битный на современном ПК, 32- или 16-битный на большинстве недорогих ЦП общего назначения за последние пару десятилетий), для каждого компилятора/реализации/версии и ЦП I' Я когда-либо слышал, что код операции ЦП для умножения определенного целочисленного размера занимает определенное количество тактов независимо от задействованных величин. Умножение данных разного размера выполняется по-разному на некоторых процессорах (например, AMD K7 имеет задержку 3 такта для 16-битного IMUL против 4 для 32-битного).

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

При этом, если одно или оба значения являются константами времени компиляции, компилятор может избежать оператора умножения ЦП и оптимизировать операторы сложения или сдвига битов для определенных значений (например, 1, очевидно, не используется, любая сторона 0 = => 0 результат, * 4 иногда можно реализовать как << 2). Нет ничего особенного в методах остановки, таких как сдвиг битов, используемых для больших чисел, но меньший процент таких чисел может быть оптимизирован в той же степени (например, есть больше степеней двойки, для которых умножение может быть выполнено с использованием сдвига битов влево - от 0 до 1000, чем от 1000 до 2000).

Это сильно зависит от архитектуры и модели процессора.

В прежние времена (приблизительно 1980-1990 гг.) количество единиц в двух числах было фактором — чем больше единиц, тем больше времени требовалось для умножения [после корректировки знака, поэтому умножение на -1 было не медленнее, чем умножение на 1, но умножение на 32767 (15 единиц) было заметно медленнее, чем умножение на 17 (2 единицы)]. Это потому, что умножение по существу:

unsigned int multiply(unsigned int a, unsigned int b)
{  
    res = 0;  
    for(number of bits)
    {
        if (b & 1)
        {
           res += a;
        }
        a <<= 1;
        b >>= 1;
    }
}

В современных процессорах умножение выполняется довольно быстро в любом случае, но 64-битное умножение может быть на один или два такта медленнее, чем 32-битное значение. Просто потому, что современные процессоры могут «позволить себе» уложить всю логику для этого за один цикл — как по скорости самих транзисторов, так и по площади, которую эти транзисторы занимают.

Кроме того, в старые времена часто были инструкции для получения результатов 16 x 16 -> 32 бит, но если вы хотели 32 x 32 -> 32 (или 64), компилятор должен был вызвать библиотечную функцию [или встроенную такую ​​​​ функция]. На сегодняшний день я не знаю ни одного современного высокопроизводительного процессора [x86, ARM, PowerPC], который не может выполнять по крайней мере 64 x 64 -> 64, некоторые делают 64 x 64 -> 128, и все это в одной инструкции (не всегда один цикл, хотя').

Обратите внимание, что я полностью игнорирую тот факт, что «наличие данных в кеше является важным фактором». Да, это фактор — и это немного похоже на игнорирование сопротивления ветра при движении со скоростью 200 км/ч — это совсем не то, что вы игнорируете в реальном мире. Впрочем, для ЭТОГО обсуждения это совершенно неважно. Точно так же, как люди, создающие спортивные автомобили, заботятся об аэродинамике, чтобы сложное [или простое] программное обеспечение работало быстро, требуется определенная забота о содержимом кеша.

Для всех намерений и целей одинаковая скорость (даже если бы были различия в скорости вычислений, они были бы неизмеримы). Если вам интересно, вот ссылка на сравнение различных операций ЦП: http://www.agner.org/optimize/instruction_tables.pdf.