que emiten es más rápido static_cast <int>() o int()

Question

Trate de ver qué elenco es más rápido (no es necesario que sea mejor): nuevo caso de C++ o viejo elenco de estilo C de la moda. ¿Algunas ideas?

Answer 1

No debería haber ninguna diferencia si compara int() con equivalente funcionalidad de static_cast<int>().

Usando VC2008:

double d = 10.5; 
013A13EE fld   qword ptr [__real@4025000000000000 (13A5840h)] 
013A13F4 fstp  qword ptr [d] 
    int x = int(d); 
013A13F7 fld   qword ptr [d] 
013A13FA call  @ILT+215(__ftol2_sse) (13A10DCh) 
013A13FF mov   dword ptr [x],eax 
    int y = static_cast<int>(d); 
013A1402 fld   qword ptr [d] 
013A1405 call  @ILT+215(__ftol2_sse) (13A10DCh) 
013A140A mov   dword ptr [y],eax 

Obviamente, es 100% igual!

Answer 2

Eche un vistazo al ensamblaje con cada método. Si es diferente, use un perfilador.

Answer 3

Son los mismos que se resuelven durante el tiempo de compilación y no hay sobrecarga de tiempo de ejecución. Incluso si hubiera alguna diferencia, realmente no me molestaría demasiado con estas pequeñas (ni siquiera micro) optimizaciones.

Answer 4

No hay diferencia en absoluto.

Cuando se trata de tales construcciones básicas como un único molde, una vez que dos construcciones tienen el mismo significado semántico, su performace será perfectamente idénticos, y el código de máquina generado para estas construcciones será el mismo.

Answer 5

Cuando su elección hace poca diferencia en el código, elegiría el que les parezca más familiar a los programadores posteriores. Hacer código más fácil de entender por los demás siempre vale la pena considerarlo. En este caso, me quedaría con int(…) por ese motivo.

Answer 6

Creo que el resultado real es la implementación definida. Debería verificarlo en su versión del compilador. Pero creo que dará el mismo resultado en la mayoría de los compiladores modernos. Y en C++ no debe usar C-cast, en su lugar use C++ casts - le permitirá encontrar errores en tiempo de compilación.

Answer 7

Como la mayoría de la gente dice que uno espera que estos tengan la misma velocidad, aunque estés a merced de tu compilador ... y esa no siempre es una situación muy feliz. Sigue leyendo para historias de guerra.

Dependiendo de su compilador y el modelo particular de núcleo de procesador que ejecuta el programa de la velocidad de float f; int i(f);, float f; int i = (int)f; y float f; int i = static_cast<int>(f); y sus semejantes (incluyendo las variaciones que implican tipos dobles, largos y sin signo) puede ser atrociously lento - un orden de magnitud peor de lo esperado El compilador puede emitir instrucciones que alteran los modos internos del procesador, lo que hace que las tuberías de instrucciones se descarten. Esto es, en efecto, un error en el elemento de optimización del compilador. He visto casos en los que uno sufre el tipo de costos de 40 ciclos de reloj mencionados en this analysis, en cuyo punto tiene un cuello de botella de rendimiento importante, inesperado e irritante con AFAIK ninguna solución genérica totalmente agradable, robusta. Hay alternativas que implican al ensamblador pero AFAIK no redondean el punto flotante al entero de la misma manera que los moldes. Si alguien sabe algo mejor, estoy interesado. Espero que este problema se confine en breve a los compiladores/hardware heredados, pero necesita su ingenio.

P.S. No puedo acceder a ese enlace porque mi firewall lo bloquea como relacionado con los juegos, pero a Google cache of it es suficiente para demostrar que su autor sabe más sobre él que yo.