Durante la lectura a través del kit de entrenamiento 70-536, se indica:.NET optimizado Int32
El tiempo de ejecución optimiza el rendimiento de tipos de enteros de 32 bits (Int32), por lo utilizar esos tipos de contadores y otras variables integradas de acceso frecuente .
¿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 al contrario de lo que otras personas en este hilo pueden decir, hasta que mida el beneficio de una cosa tan pequeña como esta, es solo en un beneficio percibido.
Esa es una forma divertida de expresarlo. 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, prefiero 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 aún puede ser)
Los 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.
No existe un tipo de datos integral "predeterminado" desde el punto de vista de la CPU, "tipado" está limitado por los códigos de operación del registro legal. –
cierto. Por defecto me refiero a los tamaños de datos que la CPU puede procesar de manera más eficiente. Menos de 32 bits significa más trabajo en operaciones de carga/almacenamiento (porque parte de la lectura/escritura debe enmascararse), y más de 32 bits requiere instrucciones más largas (y puede, en algunas CPU también ser más lento en sí mismo) – jalf
Hay una distribución .NET para x64. – Cheeso
http://en.wikipedia.org/wiki/64-bit sugiere (que puede encontrar una fuente más autorizada, éste es el primero que he encontrado) que las ofertas "64 bits" de Microsoft utilizan punteros de 64 bits con enteros de 32 bits.
http://www.anandtech.com/guides/viewfaq.aspx?i=112 (y no sé cómo digno de confianza es) dice,
Con el fin de mantener el código hinchazón al mínimo, AMD realmente establece el tamaño del operando datos por defecto a 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 :)).
He visto esto también –
En MSVC, long long es un entero de 64 bits. –
Una CPU de 32 bits maneja los 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 longs, pero eso solo es especulación por mi parte.
Está afirmando que las CPU de 64 bits manejan enteros de 64 bits más rápido que los enteros de 32 bits: ¿pero no es eso solo una especulación de su parte? – ChrisW
ChrisW: No leyó mi respuesta detenidamente. No especulé; Le expliqué que para evitar la degradación del rendimiento debido a la desalineación, debe rellenar sus enteros de 32 bits con 32 bits adicionales. Esto no es especulación, este es un hecho bien conocido. –
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.
Puede encontrar la publicación here.
Pregunta de interés – juan