[Info-vax] x86-64 VMS executable image sizes and memory requirements ?

already5chosen at yahoo.com already5chosen at yahoo.com
Sun Dec 22 06:13:48 EST 2019


On Saturday, December 21, 2019 at 11:30:27 PM UTC+2, osuv... at gmail.com wrote:
> On Saturday, December 21, 2019 at 11:16:59 AM UTC-5, already... at yahoo.com wrote:
> > Few numbers for clang/LLVM on x86-64 (not VMS, of course)
> > 
> > Option .text size
> > -O0 75456
> > -Oz 45772
> > -Os 44992
> > -O1 56836
> > -O2 45220
> > -O3 46084
> > 
> 
> Clearly, DEC C isn't clang. Building the sqlite3shr shareable image on alpha
> with different /optimization levels gives (size in disk blocks):
> 
>   sqlite3shr-O0.exe;1             2676
>   sqlite3shr-O1.exe;1             2405
>   sqlite3shr-O2.exe;1             3513
>   sqlite3shr-O3.exe;1             3710
>   sqlite3shr-O4.exe;1             3710
>   sqlite3shr-O5.exe;1             3820
> 
> If I link /notrace, however, the file sizes change to:
>   sqlite3shr-O0.exe;1             2099
>   sqlite3shr-O1.exe;1             1835
>   sqlite3shr-O2.exe;1             1837
>   sqlite3shr-O3.exe;1             1962
>   sqlite3shr-O4.exe;1             1962
>   sqlite3shr-O5.exe;1             2059
> 
> I presume line number tracking is a lot more complicated for optimized code.
> 
> The respective $CODE$ sizes are:
>   sqlite3shr-O0.map;1           880492
>   sqlite3shr-O1.map;1           749156
>   sqlite3shr-O2.map;1           773240
>   sqlite3shr-O3.map;1           837496
>   sqlite3shr-O4.map;1           837496
>   sqlite3shr-O5.map;1           886824

Quite possibly, DEC C vs clang is just one of the reasons.
Another reason could be register allocation. When you have only 16 registers then good register allocation is very important no only for speed, but for a code size as well. It is much less critical when you have 32 registers. In the later case, I'd imagine that any allocator which is not completely idiotic, will give about the same code size (but not the same speed).

But yes, DEC C and LLVM/clang are probably quite different in that that LLVM/clang takes "don't optimize" command much more literally.
In that regard, it is similar to MSVC and gcc.


BTW, clang optimizer (even at -O2) can produce horrendously bloated code when it can see an opportunity for vectorization. But I would imagine that neither of our test cases presents it with such opportunities.





More information about the Info-vax mailing list