2009-10-19 21 views
10

Tengo un proyecto VC++ (2005) que genera dlls de 32 bits y de 64 bits. La dll de 32 bits tiene 1044 KB, mientras que la versión de 64 bits tiene 1620 KB. Tengo curiosidad por qué el tamaño es tan grande. ¿Es solo por el tamaño de la dirección más grande, o hay una opción de compilación que me falta?Tamaño de dll de 64 bits 50% más grande que 32-bit

+0

¿Está estáticamente de vínculos de la ejecución? Entonces, sin duda, es el tiempo de ejecución el que agrega _most_ de la sobrecarga. – dirkgently

+0

No hay suficiente información para proporcionar una respuesta significativa. Cualquier cosa provista será pura especulación. –

+0

Como anécdota, el tamaño del código x64 aumenta en un 50% a 66% con respecto al código x86 equivalente. Supuse que el aumento se debió principalmente al tamaño de los punteros (incluidas las direcciones de destino de llamadas de función). Sin embargo, no he visto ningún tipo de estudio/análisis riguroso; Creo que definitivamente sería interesante, espero que alguien publique un puntero. –

Respuesta

13

Tal vez su código contiene muchos apuntadores.

The Free Lunch Is Over

....

(Aparte: He aquí una anécdota para demostrar “el espacio es la velocidad” que recientemente llegó a mi equipo compilador El compilador utiliza la misma base fuente. para los compiladores de 32 bits y de 64 bits; el código es solo compilado como un proceso de 32 bits o uno de 64 bits. El compilador de 64 bits obtuvo una gran d del rendimiento de línea base ejecutándose en una CPU de 64 bits, principalmente porque la CPU de 64 bits tenía muchos más registros para trabajar con y tenía otras características de rendimiento del código . Todo bien y bien ¿Pero qué sobre los datos? Yendo a 64 bits no hicieron cambiar el tamaño de la mayoría de los datos en memoria, excepto que de punteros curso en particular eran ahora dos veces el tamaño que eran antes. Da la casualidad que nuestro compilador utiliza punteros mucho más fuertemente en sus datos internos estructuras que la mayoría de otros tipos de aplicaciones lo haría jamás. Dado que punteros ahora eran 8 bytes en lugar de 4 bytes, un aumento de tamaño de datos puro, vimos un aumento significativo en el conjunto de trabajo del compilador de 64 bits . Eso grande conjunto de trabajo causó una pena de rendimiento que compensa casi exactamente el aumento de rendimiento ejecución de código que habíamos obtenido de ir al procesador más rápido con registros más. Como de este escrito, el compilador de 64 bits funciona a la misma velocidad como el compilador de 32 bits, incluso aunque la base de origen es el mismo para tanto y el procesador 64 bits ofrece un mejor rendimiento de procesamiento en bruto. espacio es la velocidad.)

+2

Tenga en cuenta que este fragmento habla del tamaño de los datos, no del código. Pero creo que los resultados y las razones serán similares para el código y los datos. –

+0

Eso es muy interesante, gracias por publicar –

2

Su tamaño del puntero se ha duplicado, por lo que si usted tiene un montón de punteros en su código, el ejecutable puede crecer fácilmente en un 50%.

3

x86-64 tiene más registros. Como resultado, los códigos de operación necesitan más bits para especificarlos. Además, según la tradición x86 puede especificar partes de un registro, y ahora tiene un registro parcial de 32 bits. Las instrucciones que no usan registros son raras, por lo que estos cambios afectan a casi todas las instrucciones. Como x86-64 sigue siendo un ISA de longitud variable CISC, no significa que cada instrucción creció de 32 a 64 bits, pero hay un crecimiento definido.

Otro cambio es que movq, el código de operación para establecer un registro a una constante requiere 64 bits constantes (pero otras constantes en códigos de operación todavía son de 32 bits)

+0

Además, cada instrucción que accede a uno de los registros extendidos (r8-r15 o xmm8-xmm15) necesita usar el prefijo REX, que agrega 4 bits adicionales al tamaño de cada instrucción. No importa si son operaciones de 64 bits o no; por ejemplo, addl% eax,% ebx lo hará 4 bits menos que addl% eax,% r8d. (Los compiladores deben tener esto en cuenta y usar registros que den el tamaño de código más corto cuando sea posible, pero no sé específicamente si Visual C lo hace). –

Cuestiones relacionadas