Почему умножение является более дешевым, чем деление?
Много преобразований в и от строк. Обычно это - знак, что разработчик не соглашается с тем, что идет и просто пробует случайные вещи, пока что-то не работает. Например, я часто видел код как это:
object num = GetABoxedInt();
// long myLong = (long) num; // throws exception
long myLong = Int64.Parse(num.ToString());
, когда то, что они действительно хотели, было:
long myLong = (long)(int)num;
3 ответа
Подумайте об этом с точки зрения элементарных операций, которые аппаратное обеспечение может более легко реализовать - сложить, вычесть, сдвинуть, сравнить. Умножение даже в тривиальной установке требует меньшего количества таких элементарных шагов - плюс, оно позволяет усовершенствовать алгоритмы, которые работают еще быстрее - см., Например, здесь ... но оборудование обычно не использует их (кроме возможно чрезвычайно специализированное оборудование). Например, как сказано в URL-адресе википедии: «Тоом-Кук может выполнить умножение в кубе размером N за пять умножений размера N» - это действительно довольно быстро для очень больших чисел (алгоритм Фюрера, довольно недавняя разработка, может сделать Θ (n ln (n) 2Θ (ln * (n))) - опять же, см. страницу википедии и ссылки оттуда).
Division просто невероятно медленнее, как - снова - согласно википедии ; даже лучшие алгоритмы (некоторые из которых РЕАЛИЗОВАНЫ в HW, просто потому что они нигде не такие сложные и сложные, как самые лучшие алгоритмы умножения ;-) не могут сравниться с алгоритмами умножения.
Просто для количественной оценки проблема с не такими уж большими числами, вот некоторые результаты с gmpy , простой в использовании оболочкой Python вокруг GMP , которая, как правило, имеет довольно хорошие реализации арифметики, хотя не обязательно самые последние и самые сильные хрипы. На медленном (первого поколения ;-) Macbook Pro:
$ python -mtimeit -s'import gmpy as g; a=g.mpf(198792823083408); b=g.mpf(7230824083); ib=1.0/b' 'a*ib'
1000000 loops, best of 3: 0.186 usec per loop
$ python -mtimeit -s'import gmpy as g; a=g.mpf(198792823083408); b=g.mpf(7230824083); ib=1.0/b' 'a/b'
1000000 loops, best of 3: 0.276 usec per loop
Как видите, даже при таком небольшом размере (количество бит в числах) и с библиотеками, оптимизированными точно такими же одержимыми скоростью людьми, умножение на Reverserocal может сэкономить 1/3 времени, необходимого для деления.
The CPU operation for (float) division is much more complicated than multiplication. The CPU has to do more. I am far from knowledgeable about hardware, but you can find a lot of info about common division implementation (based on newton-raphson algorithms, for example).
I would also be careful about always using multiplication of the reciprocal instead of division to gain CPU performance: they may not give exactly the same results. This may or may not matter depending on your application.
Если вы вспомните начальную школу, вы вспомните, что умножение было сложнее, чем сложение и деление было труднее умножения. Для процессора все не изменилось.
Вспомните также, что вычисление обратной величины включает деление, поэтому, если вы не вычислите обратную величину один раз и не примените ее три раза, вы не увидите ускорения.