views:

429

answers:

3

I have a VC++ project (2005) that generates both 32-bit and 64-bit dlls. The 32-bit dll is 1044 KB whereas the 64-bit version is 1620 KB. I'm curious why the size is so large. Is it just because of the larger address size, or is there a compiler option that I'm missing?

+9  A: 

Maybe your code contains a lot of pointers.

The Free Lunch Is Over

....

(Aside: Here’s an anecdote to demonstrate “space is speed” that recently hit my compiler team. The compiler uses the same source base for the 32-bit and 64-bit compilers; the code is just compiled as either a 32-bit process or a 64-bit one. The 64-bit compiler gained a great deal of baseline performance by running on a 64-bit CPU, principally because the 64-bit CPU had many more registers to work with and had other code performance features. All well and good. But what about data? Going to 64 bits didn’t change the size of most of the data in memory, except that of course pointers in particular were now twice the size they were before. As it happens, our compiler uses pointers much more heavily in its internal data structures than most other kinds of applications ever would. Because pointers were now 8 bytes instead of 4 bytes, a pure data size increase, we saw a significant increase in the 64-bit compiler’s working set. That bigger working set caused a performance penalty that almost exactly offset the code execution performance increase we’d gained from going to the faster processor with more registers. As of this writing, the 64-bit compiler runs at the same speed as the 32-bit compiler, even though the source base is the same for both and the 64-bit processor offers better raw processing throughput. Space is speed.)

AraK
Note that this snippet is talking about the size of data, not the sie of code. But I think the results and reasons will be similar for code and data.
Michael Burr
That's very interesting, thanks for posting
Amit G
+2  A: 

Your pointer size has doubled, so if you have lots of pointers in your code, your executable can grow easily by 50%.

swegi
+3  A: 

x86-64 has more registers. As a result, opcodes need more bits to specify them. Also, per x86 tradition you can specify parts of a register, and you now have a 32 bit partial register. Instructions that don't use registers are rare, so these change affects almost every instruction. Since x86-64 is still a CISC variable-length ISA, it doesn't mean that each instructions grew from 32 to 64 bits, but there is a definite growth.

Another change is that movq, the opcode to set a register to a constant requires 64 bit constants (but other constants in opcodes still are 32 bits)

MSalters
Additionally, every instruction that accesses one of the extended registers (r8-r15 or xmm8-xmm15) needs to use the REX prefix, which adds an additional 4 bits to the size of each instruction. It does not matter if they are 64-bit operations or not; for instance addl %eax, %ebx will by 4 bits shorter than addl %eax, %r8d. (Compilers should take this into account and use registers giving the shorter code size where possible, but I don't know specifically if Visual C does so).
Jack Lloyd