Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!samsung!uunet!midway!iitmax!gkt
From: gkt@iitmax.iit.edu (George Thiruvathukal)
Newsgroups: comp.lang.modula2
Subject: Re: TopSpeed 3.0 First Impressions
Message-ID: <1991Jun25.154626.7877@iitmax.iit.edu>
Date: 25 Jun 91 15:46:26 GMT
References: <56F0AA44FD1F400E38@EMBL-Heidelberg.DE> <9782@sail.LABS.TEK.COM> <11710@ifi.informatik.uni-stuttgart.de>
Organization: Illinois Institute of Technology / Academic Computing Center
Lines: 66

In article <11710@ifi.informatik.uni-stuttgart.de>, schoebel@bs3.informatik.uni-stuttgart.de (Thomas Schoebel) writes:

> The JPI conventions give only some gain at routines with small parameter
> sets. As soon as a routine calls another or the size of it is more than
> a trivial one, you can examine a push orgy in the called routine
> where all parameters are moved to stack.

This is a good point.  I think we could prove that the average case behaviour
(a result of the push orgies) is probably worse than straight stack-based 
allocation of parameters.  For trivial programs (i.e. some of the programs 
commonly used for benchmarks), there might be a payoff.

> If JPI had choosen the old stack passing convention as default, their
> product would be better in general.

I have to disagree with you here.  It is quite easy to use the stack-based
parameter passing conventions by choosing an appropriate compiler flag.  You
would have to own the SourceKit and rebuild it with the supplied project files.
I have a feeling, however, you really meant to say that people in general would
be more happy if JPI had used the stack-based parameter passing by default for
reasons of compatibility with existing libraries and our agreement on the 
debatable nature of the alleged "performance improvement."

> Another question concerning benchmarks: Most of them are short
> routines with few parameters. Did this JPI imply to choose
> register passing? What about relevancy of such benchmarks??

As I mentioned, the practice of benchmarking in the context of software vendors
should be taken with a grain of salt.  As yet, I have not seen a vendor publish
a benchmark result which was based on non-trivial programs.  I am under the 
impression that the choice of the JPI calling convention is based on two
points:
  1. The one you made above. Simple programs with few parameters tend to
     compile well.  These programs are characterised by graphs (for the 
     allocation of registers) which have minimal, if any, conflicts.  What
     does this mean?  Well, it means that the push orgies to which Thomas
     alluded are virtually non-existant.  Conclusion: such programs are
     guaranteed to compile better with a register-based calling convention
     than a stack-based calling convention.

  2. Mainstream programming style.  Even to this day, programmers tend to
     use many global variables (even if their use is potentially confined
     to a handful of procedures.  While the rationale for doing so differs
     from programmer to programmer, many programmers I know do so because 
     they are aware of the overhead of procedure calls and compiler 
     optimization techniques.  Of course, many of the programmers I know
     really do not believe in structured programming.  They make claims to
     the effect of "structured programs cannot possibly be efficient."  In
     any event, programs which are written in the mainstream programming
     style tend to be characterized by register allocation graphs which are
     similar to the ones described for trivial programs.

> In practice, I believe, register passing will be worthy
> only if you manually control it. In general, it should be turned
> off for better results.

You can.  Check out the pragmas.  There is one which you can use which 
constricts the compilers attempt to allocate registers.  Since I cannot 
remember what it is, please look it up.

-- 
George Thiruvathukal

Laboratory for Parallel Computing and Languages
Illinois Institute of Technology
Chicago