🚀 go-pugleaf

On 8 Oct 90 01:13:27 GMT, brnstnd@kramden.acf.nyu.edu (Dan Bernstein) said:

brnstnd> It's unfortunate that people are so blind to the benefits of
brnstnd> hand optimization. Fine, you stay away from quickpick; just let
brnstnd> me write my code efficiently. Piercarlo, do you want to argue
brnstnd> this one again?

Yup! Of course! :-). But I am little busy now, so inflicting on the
tired masses another one of my treatises will have to wait a bit.

However, just to remind you of the gist of the argument: I object to
compilers rewriting a program's logic behind my back -- I think that
this should be done at the source level, either by the programmer alone
or by the programmer plus a programmatic assistant.

I do not object to:

* compilers doing their best to generate efficient code that _faithfully
reflects the logic_ in my source, if the source is expressed in a low
level language,

* compilers working even harder to generate efficient code that
_achieves the effects prescribed_ by my source, if the source is
expressed in a high level language.

I object to compilers that try to generate the best code that _achieves
the same effect as the logic_ of my source, when the source is expressed
as a low level language.

Just to make some obvious example: if I write three nested loops to
multiply matrixes 'm' and 'n', I want the compiler to generate code for
those three nested loops as I have written them -- if I write 'm * n',
the compiler can implement the '*' operator as it wants.

	For example on vector machines it is advantageous to write
	the three nested loops in a different order than scalar
	machines, but if I write three loops their order should not be
	changed -- if I write three nested loops it must be assumed that
	I know what I am doing, and it then falls on me to provide
	the optimal oder for the architecture I am using.

	On the other hand, if I write '*' the compiler can decide
	whether to generate the three nested loops for matrix multiply,
	and in which order, generating or not vector instructions.

What I do not want is the compiler trying to 'understand' that the
effect of my three nested loops is matrix multiplication and substitute
its implementation of '*' instead, behind my back. This is inefficient,
dangerous, and plain stupid overall (superoptimizers are just an amusing
joke).

Except maybe for the dusty deck/hapless programmer problem. But then I
believe that the solution to the dusty deck problem is not the compiler
doing hazardous transformations on a low level representation of the
source of the dusty deck, but on direct source level transformations
(dust off that deck!).

	Continuining the example above, the right thing would be to use a
	source tranformer, hopefully under programmer control, to change
	the three nested loops into an invocation to '*'.

In the dirty commercial world there are lots of companies that earn a
living dusting off decks. I wish that in the research world user
assisted source level transformation algorithms became more popular
outside the Lisp/AI community. It is a fascinating research subject,
more so I think than debugging aggressive optimizers.

I would suggest rereading Knuth on this specific subject, and Denning on
SDRAWKCAB for the general idea.
--
Piercarlo "Peter" Grandi           | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk