.net - type - vb net long integer
.NET Optimized Int32 (5)
Mientras lee el kit de entrenamiento 70-536, dice:
El tiempo de ejecución optimiza el rendimiento de los tipos enteros de 32 bits (Int32), por lo tanto, utilice esos tipos para los contadores y otras variables integrales a las que se accede con frecuencia.
¿Esto solo se aplica en un entorno de 32 bits? ¿Int64 toma el control en un entorno de 64 bits, o es Int32 todavía la mejor opción?
A menos que planee que el valor supere los 2 mil millones, use un valor entero. No hay ninguna razón para usar espacio adicional para un beneficio de rendimiento percibido.
Y, contrariamente a lo que otras personas en este hilo pueden decir, hasta que midas el beneficio de una cosa tan pequeña como esta, es solo en un beneficio percibido.
Esa es una manera divertida de decirlo. El tiempo de ejecución no tiene mucho que ver con eso. La CPU está diseñada para procesar enteros de 32 bits, por lo que son los más eficientes de usar.
En un entorno de 64 bits, nuevamente depende de la CPU. Sin embargo, en las CPU x86 al menos (que, según mi leal saber y entender, es el único lugar donde se ejecuta .NET), los enteros de 32 bits siguen siendo los predeterminados. Los registros simplemente se han expandido para que puedan ajustarse a un valor de 64 bits. Pero 32 sigue siendo el predeterminado.
Por lo tanto, prefiera los enteros de 32 bits, incluso en el modo de 64 bits.
Editar: "predeterminado" probablemente no sea la palabra correcta. La CPU solo admite una serie de instrucciones, que definen qué tipos de datos puede procesar y cuáles no. No hay un "default" allí. Sin embargo, generalmente hay un tamaño de datos que la CPU está diseñada para procesar de manera eficiente. Y en x86, en el modo de 32 y 64 bits, eso es enteros de 32 bits. Los valores de 64 bits generalmente no son más caros, pero sí significan instrucciones más largas. También creo que al menos los Pentium 4 de 64 bits fueron significativamente más lentos en operaciones de 64 bits, aunque en CPU recientes, esa parte no debería ser un problema. (Pero el tamaño de la instrucción todavía puede ser)
Valores más pequeños que 32 bits son algo más sorprendentes. Sí, hay menos datos para transferir, lo cual es bueno, pero la CPU aún captura 32 bytes a la vez. Lo que significa que tiene que enmascarar parte del valor, por lo que estos se vuelven aún más lentos.
Una CPU de 32 bits maneja enteros de 32 bits más rápido. Una de 64 bits maneja enteros de 64 bits más rápido; solo piénselo: o bien debe cambiar los bits por 32 bits todo el tiempo, o desperdiciar 32 bits por cada 32 bits, que es esencialmente lo mismo que usar una variable de 64 bits sin las ventajas de una variable de 64 bits. Otra opción sería construir circuitos adicionales en la CPU para que el cambio no sea necesario, pero obviamente eso aumentaría los costos de producción. Esto es lo mismo para las CPU de 32 bits que manejan variables de 16 bits u 8 bits.
No estoy seguro, pero no me sorprendería si la versión de 64 bit de .NET Framework estuviera un poco más optimizada para usar los largos, pero eso solo es especulación por mi parte.
http://en.wikipedia.org/wiki/64-bit sugiere (puede encontrar una fuente más autorizada, esta es la primera que encontré) que las ofertas de "64 bit" de Microsoft usan punteros de 64 bits con 32- bits enteros .
http://www.anandtech.com/guides/viewfaq.aspx?i=112 (y no sé lo confiable que es) dice,
Para mantener la saturación del código al mínimo, AMD realmente establece el tamaño predeterminado del operando de datos en 32 bits en el modo de direccionamiento de 64 bits. La motivación es que los operandos de datos de 64 bits probablemente no sean necesarios y podrían perjudicar el rendimiento; en aquellas situaciones en las que se desean operandos de datos de 64 bits, se pueden activar utilizando el nuevo prefijo REX (woohoo, otro prefijo de instrucción x86 :)).
Scott Hanselman publicó un artículo que aborda las diferencias entre el código administrado de 32 y 64 bits en su blog de hoy. Para resumir, básicamente solo los punteros cambian de tamaño, los enteros son todavía 32 bits.
Puedes encontrar la publicación aquí .