🚀 go-pugleaf

In article <607@ecrcvax.UUCP> micha@ecrcvax.UUCP (Micha Meier) writes:
>In article <184@quintus.UUCP> ok@quintus () writes:
>>A fast compiler is well worth having, but I think it is better for Prolog
>>users in the long run if vendors try to make faster compilers *in Prolog*.
>	I absolutely agree, but the question I am raising is
>	"is that possible?" and "how can it be done?" ...
>	I've seen quite a few Prolog compilers in Prolog, and all of them
>	are really *slow* compared to the C version. ...
>	My compiler spends 56 units in the lexical analysis, 90 units
>	in parsing, 47 units in the second pass and 25 units in the
>	code generation (and other units elsewhere).

Meier's figures summarise as:
	reading terms:	2/3 of total
	compiling:	1/3 of total
The ratio isn't quite that extreme in Quintus Prolog, more like 3/5 to 2/5.
Suppose Quintus were to rewrite our compiler in OukErgon (the language that
does no work at all, so is infinitely fast).  There's a 40% speedup.  If
_that's_ all we'd get from OukErgon, what price C?

My answer to Meier's questions are
 -- yes, it is possible.
 -- here is how it can be done:
    (a) If going through a WAM-like stage, improve the interpreter (if not
	generating native code) or the macros (if generating native code).
	Even Quintus Prolog could be speeded up; the trick is to do it in
	a portable way.  If you speed the emulator up, the compiler goes
	faster *and* the generated code goes faster.  If you rewrite the
	compiler in C, that does *nothing* for the user's code.
    (b) Make the compiler as clean and pure as you can.  This is likely,
	if done well, to result in *large* improvements.  I haven't seen
	"quite a few" Prolog compilers in Prolog, only about 6.  Some of
	them were quite shockingly ugly Prolog code, hacks all over the
	place.  Oddly enough, those were the slower ones.
    (c) Do better indexing (blush).  This will speed up the user's code,
	and a well-written Prolog compiler will have quite a few tables,
	especially in code-generation, so the compiler is likely to go
	faster, even doing more work.
    (d) Write an "optimising" compiler, that is free to take longer than
	would be tolerable for incremental development, and that does a
	good job of spotting determinacy, common subexpressions, special
	cases, &c, and then compile the usual compiler with it.  (Step
	(b) is an important prerequisite for this.)

The only way we'll find out whether it is possible to write faster
compilers in Prolog is to TRY.  People who sell Prolog systems must not
take the performance of present compilers as licence to run whimpering
to C, but as a stimulus to improve their Prolog systems.  (In the
interests of existing customers, better a fast compiler in C than a
slow compiler in Prolog, but that must not be regarded as anything but
a temporary expedient to be tolerated for the shortest possible time.)