Re: Sizes of executables from VMS (was UNIX) Compilers

[arny@cbnewsl.att.com (arny.b.engelson)]

In article <68773@cc.utah.edu> RCAPENER@cc.utah.edu writes:
>In article <1990Jun8.213230.10693@cbnewsl.att.com>,
>arny@cbnewsl.att.com (arny.b.engelson) writes:
>
>	[ Hello World code and other stuff deleted ]
>
>> Ada executable =  6 blocks (512 byte blocks)
>> C   executable = 87 blocks   "
>
>I can't either, since I assume you already know that Ada (and almost all
>other languages on VAX-VMS) link in the shared libraries by default, while
>C does not.  To do that you need a file (name it SHARE.OPT) in your SYS$LOGIN
>
>You will notice that now that the C code is linked with the shareable
>libraries, it shrinks drastically in size, and is usually smaller than
>the equivalent Ada *.exe file.
>
>This blurb was provided for the enlightenment for those in the Ada
>community that work strictly on UNIX and DOS machines.  If you link
>the non-shared libraries with C (the default), and link the shared
>libraries with Ada (also the default) on VAX-VMS, you are comparing
>apples with oranges.  Link the C generated code shared, and we have
>a fairer apples - apples comparison.  I am sure Arny knew this, and
>produced it solely for the entertainment of the VAX-VMS community.


Well, yes, if you link the C code with the shareable libraries it gets much
smaller (actually I believe it ends up to be almost the same size as the
Ada executable, give a block one way or the other), and yes this then becomes
more of an apples to apples comparison.  But, the problem is a lot of people
DON'T take these issues into account when doing language comparisons.  When
your novice programmer (or an experienced programmer in a new environment)
sits down to write some code, they will come up with the results I posted,
since there will probably be nobody there to enlighten him/her.  Depending on
when you receive the articles, you may already have seen another post of VMS
results with even worse numbers for C than mine (FYI, I am running different
versions of the products than he is).  Sure gets your attention, doesn't it?

In any case, this is part of the reason such language comparison results are
often meaningless, despite the fact that they ignore the larger issues such
as life cycle costs.  Reminds me a lot of statistics.  Which language is more
efficient?  Well, which language do you WANT to be more efficient?

  -- Arny Engelson   att!wayback!arny