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

[already5chosen at yahoo.com]

On Thursday, December 19, 2019 at 2:33:23 PM UTC+2, osuv... at gmail.com wrote:
> On Thursday, December 19, 2019 at 5:26:59 AM UTC-5, Simon Clubley wrote:
> > On 2019-12-18, John Reagan <xyzzy1959 at gmail.com> wrote:
> > >
> > > We're building everything NOOPTIMIZE so it isn't worth looking at.
> > >
> > > That said, 
> > >
> > > EDTSHR.EXE, Alpha, optimized: 493 blocks on disk, 179,712 bytes of code
> > > EDTSHR.EXE, Itanium, optimized: 724 blocks on disk, 302,960 bytes of code
> > > EDTSHR.EXE, x86, NOT optimized: 589 blocks on disk, 227,120 bytes of code
> > >
> > 
> > Thanks, John.
> > 
> > I'm amused that x86 not optimised is better than Itanium optimised. :-)
> > 
> > Code density on Alpha is lousy compared to VAX and from what I could tell
> > from reading the Itanium manuals, Itanium appeared to have even worse
> > code density.
> 
> My experience with the C compiler is that optimized code is often larger than
> unoptimized, depending upon what you are optimizing.
> 

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

As you can see, for my test case (small test program that I am playing recently in my spare time, a mix of C and non-idiomatic C++) unoptimized code is the biggest by far.

> Itanium was designed with the assumption that compilers would improve enough to
> make full use of the VLIW. In the end, that didn't pan out. In Clair's example,
> the Itanium compilers could apparently deal with BLISS coding practices better
> than the more unstructured MACRO-32.