¿Debo usar multiplicación o división?

Question

Aquí hay una pregunta tonta y divertida:

Digamos que tenemos que realizar una operación simple donde necesitamos la mitad del valor de una variable. Hay típicamente dos formas de hacer esto:

y = x/2.0; 
// or... 
y = x * 0.5; 

Suponiendo que estamos usando los operadores estándar proporcionados con el lenguaje, lo que uno tiene un mejor rendimiento?

Supongo que la multiplicación suele ser mejor, así que trato de atenerme a eso cuando codigo, pero me gustaría confirmar esto.

Aunque personalmente estoy interesado en la respuesta para Python 2.4-2.5, no dude en publicar una respuesta para otros idiomas. Y si lo desea, no dude en publicar otras formas más elegantes (como usar operadores de turnos bit a bit) también.

Answer 1

Siempre he aprendido que la multiplicación es más eficiente.

Answer 2

Si está trabajando con números enteros o tipos de puntos no flotantes no se olvide de sus operadores bitshifting: < < >>

int y = 10; 
    y = y >> 1; 
    Console.WriteLine("value halved: " + y); 
    y = y << 1; 
    Console.WriteLine("now value doubled: " + y); 

Answer 3

La multiplicación es por lo general más rápido - ciertamente nunca más lento. Sin embargo, si no es de velocidad crítica, escriba el que sea más claro.

Answer 4

Creo que esto se está volviendo tan insignificante que sería mejor que hicieras lo que sea que haga que el código sea más legible. A menos que realice miles de operaciones, si no millones, de veces, dudo que alguien note la diferencia.

Si realmente tiene que elegir, la evaluación comparativa es el único camino a seguir. Encuentre qué función (es) le está causando problemas, luego descubra en qué parte de la función se producen los problemas y corrija esas secciones. Sin embargo, todavía dudo de que una sola operación matemática (incluso una repetida muchas, muchas veces) sea la causa de cualquier cuello de botella.

Answer 5

He leído que la multiplicación es más eficiente en C/C++; No hay idea con respecto a los idiomas interpretados: la diferencia es probablemente insignificante debido a todos los otros gastos generales.

A menos que se convierta en un problema con lo que es más fácil de mantener/legible - Odio cuando la gente me dice esto, pero es muy cierto.

Answer 6

Bueno, si asumimos que un add/Subtrack costos de operación 1, a continuación, se multiplican los costes 5, y los costos se dividen aproximadamente 20.

Answer 7

La multiplicación es más rápido, la división es más preciso. Vas a perder cierta precisión si su número no es una potencia de 2:

y = x/3.0; 
y = x * 0.333333; // how many 3's should there be, and how will the compiler round? 

Incluso si se deja la cifra compilador cabo la constante invertida a una precisión perfecta, la respuesta todavía puede ser diferente.

x = 100.0; 
x/3.0 == x * (1.0/3.0) // is false in the test I just performed 

El tema de la velocidad no es más que probable que la materia en C/C++ o lenguas JIT, e incluso entonces sólo si la operación está en un bucle en un cuello de botella.

Answer 8

Haga lo que necesite.Primero piense en su lector, no se preocupe por el rendimiento hasta que esté seguro de que tiene un problema de rendimiento.

Deje que el compilador haga el rendimiento por usted.

Answer 9

La división de coma flotante es (generalmente) especialmente lenta, por lo que aunque la multiplicación de punto flotante también es relativamente lenta, es probablemente más rápida que la división de coma flotante.

Pero estoy más inclinado a responder "en realidad no importa", a menos que el perfil demuestre que la división es un poco cuello de botella frente a la multiplicación. Supongo, sin embargo, que la elección de la multiplicación contra la división no tendrá un gran impacto en el rendimiento de su aplicación.

Answer 10

Sugeriría la multiplicación en general, porque no tiene que pasar los ciclos asegurando que su divisor no sea 0. Esto no se aplica, por supuesto, si su divisor es una constante.

Answer 11

Python:

time python -c 'for i in xrange(int(1e8)): t=12341234234.234/2.0' 
real 0m26.676s 
user 0m25.154s 
sys  0m0.076s 

time python -c 'for i in xrange(int(1e8)): t=12341234234.234 * 0.5' 
real 0m17.932s 
user 0m16.481s 
sys  0m0.048s 

multiplicación es 33% más rápido

Lua:

time lua -e 'for i=1,1e8 do t=12341234234.234/2.0 end' 
real 0m7.956s 
user 0m7.332s 
sys  0m0.032s 

time lua -e 'for i=1,1e8 do t=12341234234.234 * 0.5 end' 
real 0m7.997s 
user 0m7.516s 
sys  0m0.036s 

=> ninguna diferencia real

LuaJIT:

time luajit -O -e 'for i=1,1e8 do t=12341234234.234/2.0 end' 
real 0m1.921s 
user 0m1.668s 
sys  0m0.004s 

time luajit -O -e 'for i=1,1e8 do t=12341234234.234 * 0.5 end' 
real 0m1.843s 
user 0m1.676s 
sys  0m0.000s 

=> Es sólo un 5% más rápido

conclusiones: en Python es más rápido para multiplicar que repartir, pero a medida que se acerque a la CPU mediante máquinas virtuales más avanzados o equipos conjuntos de investigación, la ventaja desaparece. Es muy posible que una futura máquina virtual de Python lo haga irrelevante

Answer 12

Escriba el que indique más claramente su intención.

Después de que su programa funcione, descubra qué es lento y hágalo más rápido.

No lo hagas al revés.

Answer 13

Siempre use lo que sea más claro. Cualquier otra cosa que hagas es tratar de burlar al compilador. Si el compilador es en absoluto inteligente, hará lo mejor para optimizar el resultado, pero nada puede hacer que el siguiente tipo no lo odie por su mala solución de cambio de bits (me encanta la manipulación de bits por cierto, es divertido. ¡Pero divertido! = Legible)

La optimización prematura es la raíz de todos los males. ¡Recuerda siempre las tres reglas de optimización!

1. No optimizar.
2. Si usted es un experto, ver regla # 1

3. Si usted es un experto y puede justificar la necesidad, a continuación, utilizar el siguiente procedimiento:

   • Código que no optimizado
   • determinar qué tan rápido es "Lo suficientemente rápido": tenga en cuenta qué requisito/historia del usuario requiere esa métrica.
   • Escriba una prueba de velocidad
   • Pruebe el código existente - Si es lo suficientemente rápido, listo.
   • Recode optimizado
   • Código de prueba optimizada. SI no cumple con la métrica, deséchela y conserve el original.
   • Si se cumple con la prueba, mantener el código original en como comentarios

También, haciendo cosas como la eliminación de bucles internos cuando no son necesarios o la elección de una lista enlazada a través de una matriz para una inserción ordenar no son optimizaciones, solo programación.

Answer 14

Esto se convierte en una cuestión más importante cuando se está programando en ensamblaje o quizás C. Me imagino que con la mayoría de los lenguajes modernos esa optimización se está haciendo por mí.

Answer 15

Tenga cuidado con "adivinar multiplicación es por lo general mejor, así que trate de cumplir con lo que cuando el código"

En el contexto de esta cuestión específica, mejor aquí significa "rápido". Lo cual no es muy útil.

Pensar en la velocidad puede ser un grave error. Hay profundas implicaciones de error en la forma algebraica específica del cálculo.

Ver Floating Point arithmetic with error analysis. Ver Basic Issues in Floating Point Arithmetic and Error Analysis.

Mientras que algunos valores de punto flotante son exactos, la mayoría de los valores de coma flotante son una aproximación; son un valor ideal más algún error. Cada operación se aplica al valor ideal y al valor de error.

Los mayores problemas provienen de tratar de manipular dos números casi iguales. Los bits más a la derecha (los bits de error) llegan a dominar los resultados.

>>> for i in range(7): 
...  a=1/(10.0**i) 
...  b=(1/10.0)**i 
...  print i, a, b, a-b 
... 
0 1.0 1.0 0.0 
1 0.1 0.1 0.0 
2 0.01 0.01 -1.73472347598e-18 
3 0.001 0.001 -2.16840434497e-19 
4 0.0001 0.0001 -1.35525271561e-20 
5 1e-05 1e-05 -1.69406589451e-21 
6 1e-06 1e-06 -4.23516473627e-22 

En este ejemplo, se puede ver que a medida que los valores se hacen más pequeños, la diferencia entre los números casi iguales a crear resultados que no son cero, donde la respuesta correcta es cero.

Answer 16

Si desea optimizar su código, pero todavía ser clara, intente esto:

y = x * (1.0/2.0); 

El compilador debe ser capaz de hacer la división en tiempo de compilación, por lo que obtener una multiplicación en tiempo de ejecución. Esperaría que la precisión sea la misma que en el caso y = x/2.0.

Donde esto puede importar MUCHO es en procesadores integrados donde se requiere emulación de coma flotante para calcular la aritmética de coma flotante.

Answer 17

Solo voy a agregar algo para la opción "otros idiomas".
C: Dado que esto es solo un ejercicio académico que realmente no hace diferencia, pensé que contribuiría con algo diferente.

Me compilé para ensamblar sin optimizaciones y miré el resultado.
el código:

int main() { 

    volatile int a; 
    volatile int b; 

    asm("## 5/2\n"); 
    a = 5; 
    a = a/2; 

    asm("## 5*0.5"); 
    b = 5; 
    b = b * 0.5; 

    asm("## done"); 

    return a + b; 

} 

compilado con gcc tdiv.c -O1 -o tdiv.s -S

la división por 2:

movl $5, -4(%ebp) 
movl -4(%ebp), %eax 
movl %eax, %edx 
shrl $31, %edx 
addl %edx, %eax 
sarl %eax 
movl %eax, -4(%ebp) 

y la multiplicación por 0,5:

movl $5, -8(%ebp) 
movl -8(%ebp), %eax 
pushl %eax 
fildl (%esp) 
leal 4(%esp), %esp 
fmuls LC0 
fnstcw -10(%ebp) 
movzwl -10(%ebp), %eax 
orw $3072, %ax 
movw %ax, -12(%ebp) 
fldcw -12(%ebp) 
fistpl -16(%ebp) 
fldcw -10(%ebp) 
movl -16(%ebp), %eax 
movl %eax, -8(%ebp) 

Sin embargo, cuando cambié aquellos int s a double s (que es lo que probablemente haría pitón), tengo esto:

división:

flds LC0 
fstl -8(%ebp) 
fldl -8(%ebp) 
flds LC1 
fmul %st, %st(1) 
fxch %st(1) 
fstpl -8(%ebp) 
fxch %st(1) 

multiplicación:

fstpl -16(%ebp) 
fldl -16(%ebp) 
fmulp %st, %st(1) 
fstpl -16(%ebp) 

no he referenciado cualquiera de este código, pero sólo examinando el código puedes ver que usar enteros, división por 2 es más corto que multiplicar por 2. Usando dobles, la multiplicación es más corta porque el compilador usa los códigos de operación de punto flotante del procesador, que probablemente corran más rápido (pero realmente no lo sé) que no usarlos para el sam operación e Así que, en última instancia, esta respuesta ha demostrado que el rendimiento de la multiplacción por 0.5 frente a la división por 2 depende de la implementación del lenguaje y la plataforma en la que se ejecuta. En última instancia, la diferencia es insignificante y es algo de lo que prácticamente nunca deberías preocuparte, excepto en términos de legibilidad.

Como nota al margen, puede ver que en mi programa main() devuelve a + b. Cuando tomo la palabra clave volátil de distancia, que no sabes lo que el ensamblaje se parece a (excluyendo la configuración del programa):

## 5/2 

## 5*0.5 
## done 

movl $5, %eax 
leave 
ret 

lo hizo tanto en la división, multiplicación y adición en una sola instrucción! Claramente, no tiene que preocuparse por esto si el optimizador es de algún tipo respetable.

Perdón por la respuesta demasiado larga.

Answer 18

Como en los mensajes # 24 (multiplicación es más rápido) y # 30 - pero a veces ambos son igual de fácil de entender:

1*1e-6F; 

1/1e6F; 

~ puedo encontrar a los dos igual de fácil de leer, y tienen que repítalos miles de millones de veces. Por lo tanto, es útil saber que la multiplicación suele ser más rápida.

Answer 19

Android Java, perfilado en el Samsung GT-S5830

public void Mutiplication() 
{ 
    float a = 1.0f; 

    for(int i=0; i<1000000; i++) 
    { 
     a *= 0.5f; 
    } 
} 
public void Division() 
{ 
    float a = 1.0f; 

    for(int i=0; i<1000000; i++) 
    { 
     a /= 2.0f; 
    } 
} 

Resultados?

Multiplications(): time/call: 1524.375 ms 
Division():   time/call: 1220.003 ms 

División es de aproximadamente 20% más rápido que la multiplicación (!)

Answer 20

técnicamente no hay tal cosa como la división, no es sólo la multiplicación por elementos inversos. Por ejemplo, nunca divide por 2, de hecho se multiplica por 0.5.niño deje de nosotros mismos que existe para un segundo - -

'División' es siempre más difícil que la multiplicación debido a la 'brecha' x por y primero hay que calcular el valor y^{-1} tal que y*y^{-1} = 1 y luego hacer la multiplicación x*y^{-1}. Si ya conoce y^{-1}, entonces no calcularlo desde y debe ser una optimización.

Answer 21

Existe una diferencia, pero depende del compilador. Al principio en vs2003 (C++) no obtuve ninguna diferencia significativa para los tipos dobles (punto flotante de 64 bits). Sin embargo, volviendo a ejecutar las pruebas en el vs2010, detecté una gran diferencia, hasta un factor 4 más rápido para las multiplicaciones. Siguiendo esto, parece que vs2003 y vs2010 generan un código de fpu diferente.

en un Pentium 4, 2,8 GHz, VS2003:

• Multiplicación: 8,09
• División: 7,97

En un Xeon W3530, VS2003:

• Multiplicación: 4.68
• División: 4.64

En un W3530 Xeon, VS2010:

• Multiplicación: 5,33
• División: 21,05

Parece que en VS2003 una división en un bucle (múltiple lo que se utilizó el divisor veces) fue traducido a una multiplicación con el inverso. En vs2010 esta optimización ya no se aplica (supongo que porque hay un resultado ligeramente diferente entre los dos métodos). Tenga en cuenta también que la CPU realiza divisiones más rápido tan pronto como su numerador es 0.0. No sé el algoritmo preciso cableado en el chip, pero tal vez depende del número.

Editar 18-03-2013: la observación de VS2010

Answer 22

En realidad hay una buena razón por la que, como regla general del pulgar multiplicación será más rápido que la división. La división de punto flotante en el hardware se realiza con algoritmos de resta condicional y de cambio ("división larga" con números binarios) o, lo más probable en la actualidad, con iteraciones como el algoritmo Goldschmidt's. Shift y resta necesita al menos un ciclo por cada bit de precisión (las iteraciones son casi imposibles de paralelizar como lo son el cambio y el agregado de la multiplicación), y los algoritmos iterativos hacen al menos una multiplicación por iteración. En cualquier caso, es muy probable que la división tome más ciclos. Por supuesto, esto no explica las peculiaridades de los compiladores, el movimiento de datos o la precisión. Sin embargo, en general, si está codificando un bucle interno en una parte sensible de un programa, escribir 0.5 * x o 1.0/2.0 * x en lugar de x/2.0 es algo razonable de hacer. La pedantería del "código que es más claro" es absolutamente cierto, pero los tres están tan cerca de la legibilidad que la pedantería es en este caso simplemente pedante.

Answer 23

Después de una discusión tan larga e interesante, aquí está mi opinión sobre esto: No hay una respuesta definitiva a esta pregunta.Como algunas personas señalaron depende de ambos, el hardware (cf piotrk y gast128) y el compilador (cf las pruebas @Javier). Si la velocidad no es crítica, si su aplicación no necesita procesar en gran cantidad de datos en tiempo real, puede optar por la claridad usando una división, mientras que si la velocidad de procesamiento o la carga del procesador son un problema, la multiplicación puede ser la más segura. Finalmente, a menos que sepa exactamente en qué plataforma se implementará su aplicación, el punto de referencia no tiene sentido. Y para la claridad del código, ¡un solo comentario haría el trabajo!

Answer 24

En primer lugar, a menos que trabaje en C o ENSAMBLAR, probablemente esté en un lenguaje de nivel superior en el que los puestos de memoria y los gastos generales generales anularán la diferencia entre multiplicar y dividir hasta el punto de irrelevancia. Por lo tanto, solo elige qué lee mejor en ese caso.

Si habla desde un nivel muy alto, no será mucho más lento para cualquier cosa que pueda utilizar. Verá en otras respuestas que la gente necesita multiplicar/dividir un millón simplemente para medir una diferencia de menos de milisegundos entre las dos.

Si todavía sientes curiosidad, desde un punto de optimización bajo nivel de vista: tiende

Dividir para tener una tubería significativamente más largo que se multiplican. Esto significa que se necesita más tiempo para obtener el resultado, pero si puede mantener el procesador ocupado con tareas no dependientes, entonces no le costará más de un múltiplo.

El tiempo que la diferencia de la tubería depende completamente del hardware. El último hardware que utilicé fue algo así como 9 ciclos para una FPU multiplicada y 50 ciclos para una FPU dividida. Suena mucho, pero luego perderías 1000 ciclos por un error de memoria, de modo que puede poner las cosas en perspectiva.

Una analogía es poner un pastel en el microondas mientras mira un programa de televisión. El tiempo total que lo alejó del programa de TV es cuánto tiempo lo puso en el microondas y lo sacó del microondas. El resto de tu tiempo aún viste el programa de TV. Entonces, si el pastel tardó 10 minutos en cocinarse en lugar de 1 minuto, en realidad no consumió más tiempo de la televisión.

En la práctica, si va a llegar al nivel de preocupación por la diferencia entre Multiplicar y Dividir, necesita comprender las tuberías, caché, puestos de ramificación, predicciones fuera de orden y dependencias de tuberías. Si esto no suena como lo que pretendía hacer con esta pregunta, entonces la respuesta correcta es ignorar la diferencia entre los dos.

Muchos (muchos) años atrás era absolutamente crítico evitar divisiones y usar siempre multiplicaciones, pero en aquel entonces los aciertos de memoria eran menos relevantes y las divisiones eran mucho peores. Estos días califico la legibilidad más alta, pero si no hay diferencia de legibilidad, creo que es una buena costumbre optar por las multiplicaciones.