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

[Kerry Main]

> -----Original Message-----
> From: Info-vax <info-vax-bounces at rbnsn.com> On Behalf Of Bill
> Gunshannon via Info-vax
> Sent: December 22, 2019 6:36 PM
> To: info-vax at rbnsn.com
> Cc: Bill Gunshannon <bill.gunshannon at gmail.com>
> Subject: Re: [Info-vax] x86-64 VMS executable image sizes and memory
> requirements ?
> 
> On 12/22/19 12:12 PM, Bob Gezelter wrote:
> > On Wednesday, December 18, 2019 at 8:21:55 PM UTC-5, Simon Clubley
> wrote:
> >> Now that VSI are starting to get user level programs such as EDT
> >> running, I was wondering how the x86-64 VMS image sizes and memory
> >> usage compares to other VMS architectures.
> >>
> >> Or is it still too early to get enough data to be meaningful ?
> >>
> >> Thanks,
> >>
> >> Simon.
> >>
> >> --
> >> Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP
> >> Walking destinations on a map are further away than they appear.
> >
> > Simon,
> >
> > The whole question of code size on x64 is a bit of a "red herring".
> >
> > In the days or the PDP-11 or early VAX processors, code size in both
> primary and secondary storage was a serious issue. Both types of storage
> were relatively expensive. To put it politely, size was King.
> 
> I used to argue about teaching efficiency with the one particular
professor
> when I still worked at the University.  He used to use the same arguments.
> Space occupied in memory and on disk is not the only effect of size of the
> executable.
> 
> >
> > The environment today is dramatically different, both in cost and
capacity.
> CPU storage has gone from hundreds of kilobytes to multiple terabytes.
> Mass storage has gone from hundreds of megabytes (e.g., RP04) to
> terabytes. In 1978, an 176-megabyte drive weighed hundreds of pounds and
> cost USD 35K (if memory serves, pardon the pun). Today, a multi-terabyte
> drive costs approximately USD 100 and easily fits in my hand.
> >
> > It is also important to compare like with like. VAX images were
routinely
> stripped of debugging information for a variety of reasons. On newer
> architectures, this may or may not be the case.
> 
> All debugging information and code should be removed before it is released
> to production. Availability of excess resources is never an excuse for
sloppy
> coding.
> 
> >
> > Optimization is another issue. Unrolling loops, inline code replication,
and
> other optimizations can increase the size of the code while at the same
time
> increasing speed of execution. Early PDP-11 CPUs did not have caches,
Later
> PDP-11 and VAX CPUs did have caches, but they were minuscule by present
> standards. Combine the effects of large, multi-level caches with code
> optimization creates complex tradeoff effects (Hint: Temporal locality can
be
> quite significant in achieving high performance, but may increase code
size).
> Pipelining also advantages code with no control transfers, which means
> replication code can be advantageous). In the end, size is a poor metric
not
> particularly related to performance.
> 
> While I will agree that size is a poor metric, when taken by itself, we
always
> here people complaining about "bloatware" and screaming at Microsoft
> about it.  I don't know if it has improved but Microsoft used to ship a
lot of
> their production code with the debugging stuff still in it.  But the
notion that
> because we have all these excess resources the time should not be spent
> trying to increase efficiency is just laziness.
> 

You mean like when Microsoft shipped Windows NT Alpha flavours of Office
with all debug code loaded?

Yes, you are correct and even when it was pointed out to MS, they never
fixed this...however, I doubt laziness was the issue.

[insert your favourite conspiracy theory about how dedicated MS was to
Alpha]

And yes, even with the debug code loaded, Office on Windows NT Alpha was, at
the time, still faster than Windows NT X86 versions of Office.

Ah well, water under the bridge as some might say ...

Regards,

Kerry Main
Kerry dot main at starkgaming dot com