¿Cómo puedo comparar el rendimiento de log() y la división fp en C++?

Question

Estoy usando una clase basada en registro en C++ para almacenar valores muy pequeños de punto flotante (ya que los valores de lo contrario van más allá del alcance de double). Como estoy realizando una gran cantidad de multiplicaciones, esto tiene el beneficio adicional de convertir las multiplicaciones en sumas.

Sin embargo, en un cierto punto en mi algoritmo, necesito dividir un valor estándar double por un valor integer y hacer un valor basado en el registro *=. He sobrecargado el operador *= para mi clase basada en registro y el valor del lado derecho se convierte primero a un valor basado en registro ejecutando log() y luego se agrega al valor del lado izquierdo. Por lo tanto, las operaciones realmente realizadas son división de coma flotante, log() y suma de coma flotante.

Mi pregunta si sería más rápido convertir primero el denominador en un valor basado en el registro, que reemplazaría la división de coma flotante con resta de punto flotante, produciendo la siguiente cadena de operaciones: dos veces log(), coma flotante resta, suma de punto flotante.

Al final, esto se reduce a si la división de coma flotante es más rápida o más lenta que log(). Sospecho que una respuesta común sería que esto depende del compilador y de la arquitectura, así que diré que utilizo gcc 4.2 de Apple en darwin 10.3.0. Aún así, espero obtener una respuesta con un comentario general sobre la velocidad de estos dos operadores y/o una idea sobre cómo medir la diferencia yo mismo, ya que podría haber más cosas aquí, por ejemplo. ejecutando los constructores que hacen la conversión de tipo, etc.

¡Salud!

Answer 1

¿Se divide por el mismo número entero varias veces? Si es así, puedes multiplicar por 1./yourInteger, y solo dividir una vez. Eso sería más rápido de lo que sea posible.

En cuanto a su pregunta real, no solo depende del compilador y la arquitectura, sino también de la microarquitectura y de los datos.

En su plataforma particular (darwin/x86), para el hardware actual i5/i7: ~ 24 ciclos para dividir (1), ~ 35 ciclos para log() (2). Sin embargo, debido a que divide solo usa una sola ranura de despacho de instrucciones, el motor de reordenación del hardware puede hacer otros cálculos útiles mientras la división está en vuelo; log() se implementa en software, por el contrario, por lo que hay menos oportunidades para que el procesador eleve otros cómputos a la latencia del logaritmo. Esto significa que en la práctica, divide a menudo será un poco más rápido.

1) A partir de la optimización de Intel Manual

2) Medido llamando log() en un bucle estrecho y el uso de mach_absolute_time() para obtener el tiempo de la pared.

Answer 2

El principal problema con la división es que, aunque es una instrucción única en la mayoría de las CPU modernas, generalmente tiene un alto latency (31 ciclos en PowerPC - no estoy seguro de lo que está en x86). Sin embargo, parte de esta latencia puede ocultarse si tiene otras instrucciones no dependientes que se pueden emitir al mismo tiempo que la división. Por lo tanto, la respuesta dependerá en cierta medida del tipo de combinación de instrucciones y dependencias que tenga en el ciclo que contenga su división (sin mencionar qué CPU está usando).

Habiendo dicho eso, mi intuición es que la división será más rápida que una función de registro en la mayoría de las arquitecturas.

Answer 3

Estoy bastante seguro de que hacer un cálculo de registro a través de cualquier algoritmo va a ser bastante más caro que incluso la división FP.

Por supuesto, la única manera de estar seguro es codificarlo y medir el rendimiento del código. Según su descripción, parece que no debería ser demasiado difícil implementar ambas versiones y probarlas una al lado de la otra.

Answer 4

En la arquitectura x86, los logaritmos toman mucho más tiempo que las divisiones: 85 ciclos (rendimiento) para FYL2X en comparación con 40 ciclos para FDIV. Me sorprendería si otras arquitecturas son muy diferentes. Ve con la división de coma flotante.