Re: Writing fast compilers... RS/6000

On 17 Aug 91 00:52:43 GMT, pardo@gar.cs.washington.edu (David Keppel) said:


pardo> Ah, yes, that reminds me of a code fragment that multiplies every
pardo> element of an array by either zero or one, then performs the
pardo> desired computation on the array.


That is the definition of the function; you offer two implementations of
this function:


pardo> for (i=0; i<N; ++i) sum += compute(a[i]) * zero_or_one[i];
pardo> for (i=0; i<N; ++i) if (cond[i]) sum += compute(a[i]);


pardo> On `normal' machines it runs slower, on a Cray it runs faster.
pardo> Ok, who's to decide what `well written code' means?


Both of these segments are badly written code, presumably. They are
*implementations* of a functions. One implementation runs faster in one
context, another in a different context.


Choosing which is implementation is best is simply impossible, a priori,
considering all possible cases. So every single possible implementation
(except for rare cases) is bad code in some context.


I cannot see how your example is different from the problem of which
sorting algorithm to use without knowing how much memory is available,
and whether tapes or disks are more efficient.


So, we have three choices here, to cover all possible cases:


1) the programmer writes one implementation, the compiler deduces from
      the implementation which function it computes and then generates code
      for a different but equivalent implementation that is more efficient.


2) Really two slightly different choices:


      2.a) the programmer writes several equivalent implementations of the
same functions, documenting which is supposed to be better in
which context.


      2.b) the programmer write one implementation of a function, then uses
tools that help him produce different versions for different
contexts.


3) the level of the interface is raised to that the function becomes a
      primitive and thus its implementation is entirely generated by the
      compiler.


I submit that 1) is clearly suboptimal, being unacceptably dangerous and
convoluted, that 3) is the ideal solution, that 2.b) is not too bad, and
2.a) is acceptable; naturally the compiler writer has to use either 2.a)
or 2.b) in implementing 3).


I think that even in the "dusty deck" case where economic reasons may
induce people to consider 1), it is preferable as to safety to choose
2.b), and not less efficient.
--
Piercarlo Grandi | ARPA: pcg%uk.ac.aber@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@aber.ac.uk
--

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