Re: summary: speed of COMMON vs arguments

In a thread started in comp.lang.fortran on globals vs. arguments,
in article <1990Apr16.185707.15507@ux1.cso.uiuc.edu>, davies@sp20.csrd.uiuc.edu (James R. B. Davies) says:
>
> |> On such compilers and architectures, there is NO doubt that arguments
> |> passed as arguments WILL be faster (MUCH faster) than COMMON blocks.
> |> On more ancient machines/compilers, it's likely to be the other way
> |> 'round, as other respondents suggested.
>
> ...
> It is possible that a modern intelligent compiler can cut down the
> overhead from argument indirection by loading an array base address
> into a register. However, in many modern compilers this goes beyond
> what is actually done (at least beyond the basic-block level).


I guess it depends on what we mean by "ancient" vs "modern": I find it
inappropriate to qualify as "modern" a compiler that does not perform such
a fundamental optimization as keeping heavily used values in registers
(the concept of a "basic block" is not really appropriate, since it is
based on control flow rather than data usage; the "live range" for a
"hot" value such as a base address can easily be made up of pieces of
more than one basic block), no matter that you may have bought one
yesterday... diagnosing as "hot" an array's base is really rather easy,
right after loop control and induction variables.


> |> .... Many people believe they "know" which way to code for
> |> optimization, based on factoids picked up here and there or maybe
> |> on one introductory course on compiler theory taken years ago...
> |> and they generally mess things up for some compilers or architectures
>
> I think you've demonstrated this point pretty well...


Since I qualified my statements with "On such compilers and architectures",
and "for some compilers or architectures", have I really?


> The best approach might be to experiment with your compiler, and time
> how it does both ways. It's hard to make blanket statements with such
> a wide range of machine/compiler combinations available (although clearly
> some people go ahead and do so anyway ;-)


I think I know where you're coming from (typical supercomputing stuff:
programs which are often small in code size, run for hours on end on
COSTLY machines, and who knows if they'll ever have to be ported
anywhere else but that specific machine-compiler-OS), but even in that
environment I have spent too much time "undoing" presumed optimization
tricks (micro-optimimization, *coding-level* optimization) which were
hiding inappropriate algorithms (sometimes) or data structuring (often)
and precluding REAL optimization, the kind which would apply over a
wide range of compilers and architectures. I think that in most cases
it would be better if routines were coded in a straightforward way,
expressing just the algorithm you mean, with clarity and maintainability;
there is probably some juicy high-level optimization to be exploited if
needed (structure or access your matrices block-wise, find an iterative
approach which converges faster, see if a direct approach could apply),
before (if ever) you need to go to the last 5-10% gain of coding level
optimization.
Fortran is a language which allows a clever compiler much leeway in
optimizing, thanks to its simplicity and bans against aliases, etc;
if you're going all-out with coding tricks to pander to the blemishes
of one particular ("modern"?) compiler, you might as well be coding
that routine in assembler... at least that way it will STAY optimized
when the compiler's next release comes out!-) Let's rather put some
heat on our compilers' vendors to DO the optimizations which are their
proper province - "micro-level" ones!


--
Alex Martelli - CAD.LAB s.p.a., v. Stalingrado 45, Bologna, Italia
Email: (work:) staff@cadlab.sublink.org, (home:) alex@am.sublink.org
Phone: (work:) ++39 (51) 371099, (home:) ++39 (51) 250434;
Fax: ++39 (51) 366964 (work only; any time of day or night).

Return to the comp.compilers page.
Search the comp.compilers archives again.