Robert Roessler:
For me, *every* [MS] compiler upgrade in the past has seen REDUCTIONS
in code size as the code generation has gotten smarter (v4 > v5 > v6 >
vs2003 < vs2005). Grrr. This is with the same options (primarily
Lua, static linking, smallest code size and limited inlining... and
[formerly] PII/PIII code generation).
The too biggest obvious "official" changes are the new "safe"
libraries, which of course are larger - not unreasonable. A trivial
app which uses printf and atoi went from 28.5 KB to 47 KB - again,
statically linked. So we get an idea that using some of the most
common portions of the CRT will add an extra ~20 KB.
BUT an 83 KB increase on a 458 KB app???
Bytes aren't as precious as they used to be, especially on disk
size. This may or may not translate into a changed in-memory size
although since its a proportional change rather than just an addition,
it probably does go into memory. Safety is one of the better reasons
for allowing some expansion but there may also be some more default
inlining of functions or loop unrolling which can increase bulk in
pursuit of speed.
The other change (relating to code generation/size) is that the
intended target architecture model can no longer be specified... this
may be particularly unfortunate, since my own timing tests on my Core
2 Duo were showing [as expected] that the older PII/PIII model was a
better match performance-wise than the P4/Athlon models.
You do get to choose whether to use SSE or SSE2. I expect it just
became too much work to tailor optimization for multiple archaic
chips.
Neil
_______________________________________________
Scite-interest mailing list
[email protected]
http://mailman.lyra.org/mailman/listinfo/scite-interest
