c# - x64 vs x86 Consideraciones de rendimiento.Net
performance 64bit (2)
Estoy tratando de entender qué diferencias de rendimiento existen al ejecutar una aplicación nativa C # / .Net 4.0 en x64 vs x86. Entiendo las consideraciones de memoria (x64 que aborda toda la memoria, x86 limitada a 2/4 gb), así como el hecho de que una aplicación x64 utilizará más memoria (todos los punteros son 8 bytes en lugar de 4 bytes). Por lo que puedo decir, ninguno de estos debería afectar al reloj para las instrucciones del reloj, ya que la tubería x64 es lo suficientemente ancha como para manejar las instrucciones más amplias.
¿Hay un impacto de rendimiento en el cambio de contexto, debido al tamaño de pila más grande para cada hilo? ¿Qué consideraciones de rendimiento me falta en la evaluación de los dos?
Joe White te ha dado algunas buenas razones por las que tu aplicación podría ser más lenta. Los punteros más grandes (y, por lo tanto, por extensión, las referencias más grandes en .NET) ocuparán más espacio en la memoria, lo que significa que menos de su código y datos cabrán en el caché.
Hay, sin embargo, muchas razones beneficiosas por las que podría querer usar x64:
La convención de llamadas AMD64 se usa de forma predeterminada en x64 y puede ser un poco más rápida que el estándar cdecl o stdcall, con muchos argumentos pasados en los registros y utilizando los registros XMM para el punto flotante.
El CLR emitirá instrucciones SSE escalares para tratar con operaciones de punto flotante en 64 bits. En x86 recurre al uso de la pila estándar x87 FP, que es bastante más lenta, especialmente para cosas como la conversión entre ints y flotadores.
Tener más registros significa que hay muchas menos posibilidades de que el JIT tenga que derramarlos debido al registro de presión. Los registros de derrames pueden ser bastante costosos para los bucles internos rápidos, especialmente si una función se inserta e introduce presión de registro adicional allí.
Cualquier operación en enteros de 64 bits puede beneficiarse enormemente al ser capaz de encajar en un solo registro en lugar de dividirse en dos mitades separadas.
Esto puede ser obvio, pero la memoria adicional a la que puede acceder su proceso puede ser bastante útil si su aplicación requiere mucha memoria, incluso si no está llegando al límite teórico. La fragmentación puede hacer que tengas condiciones "fuera de la memoria" mucho antes de llegar a esa marca.
El direccionamiento relativo a RIP en x64 puede, en algunos casos, reducir el tamaño de una imagen ejecutable . Aunque eso no se aplica directamente a las aplicaciones .NET, puede tener un efecto en el intercambio de DLL que, de lo contrario, tendrían que reubicarse. Me interesaría saber si alguien tiene alguna información específica sobre esto con respecto a .NET y las aplicaciones administradas.
Aparte de estos, la versión x64 del tiempo de ejecución de .NET parece, al menos en las versiones actuales, realizar más optimizaciones que el equivalente de x86. Las cosas como la alineación en línea y la alineación de la memoria parecen suceder mucho más a menudo. De hecho, hubo un error hace un tiempo que impidió la inclusión de cualquier método que tomó o devolvió un tipo de valor; Recuerdo haberlo visto en x64 y no en la versión x86.
Realmente, la única forma en que podrá saber cuál es la mejor para su aplicación será realizar perfiles y pruebas en ambas arquitecturas y comparar resultados reales. Sin embargo, personalmente solo uso Any CPU siempre que sea posible y evito cualquier cosa inherentemente dependiente de la arquitectura. Esto hace que sea fácil de construir y desplegar, y es de esperar que esté más preparado para el futuro cuando la mayoría de los usuarios comiencen a cambiar a x64 exclusivamente.
Muy relacionado con "la aplicación x64 usará más memoria" está el hecho de que, con una aplicación de 64 bits, su localidad de referencia es más pequeña (porque todos los tamaños de punteros se duplican), por lo que obtiene menos kilometraje de la CPU en línea. tablero (ultra-rápido) caché. Debe recuperar los datos de la memoria RAM del sistema con mayor frecuencia, lo que es mucho más lento que el L2 e incluso el caché en chip L1.