Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!uunet!mcvax!prlb2!kulcs!bimbart
From: bimbart@kulcs.uucp (Bart Demoen)
Newsgroups: comp.lang.prolog
Subject: friends
Message-ID: <1634@kulcs.kulcs.uucp>
Date: 10 Apr 89 08:41:47 GMT
Reply-To: bimbart@kulcs.UUCP (Bart Demoen)
Organization: Katholieke Universiteit Leuven, Dept. Computer Science
Lines: 31

In response to <10073@megaron.arizona.edu> debray@arizona.edu (Saumya K. Debray) :

> commercial Prolog vendor[*] managed to compile append/3 into
> sufficiently few machine instructions that code for the whole
> procedure fit into the instruction cache of the 68020, giving huge
> LIPS numbers.  A competing vendor[*] apparently felt compelled to
> ...

with in-line native code there is not really much choice: either the code runs
in the cache, or not; with threaded code, one can carefully tune the system -
by placing code of specific intermediate instructions at the rigth place or,
as was done by some Prolog implementor(s?), invent benchmark-special-purpose
intermediate instructions (like for instance taking together the WRITE mode of
GET_LIST A3 + UNIFY_XVAL A4 + UNIFY_XVAR A3) - and then certain benchmarks will
run completely in the cache

> I have friends at both places

so have I, and one of my friends over there said enthousiastically 2 years ago
in Melbourne (ICLP4) at the stand where their Prolog was demonstrated:

	Wow, naive reverse could run completely in the cache of the SUN3, I
	wonder how fast it will be !

> ... and also because aforementioned friends are quite likely to referee my
> papers in the future ...

even your enemies have to recognise that your papers are good, but I doubt that
you have any enemies

bimbart@kulcs