🚀 go-pugleaf

In article <22078@megaron.cs.arizona.edu> debray@cs.arizona.edu (Saumya K. Debray) writes:
| merlyn@iwarp.intel.com (Randal Schwartz) writes:
| > The prolog version most likely saves results from tak(a,b,c) so that
| > they can do a quick lookup the next time around.
| 
| Look -- a program either does something, or it doesn't [*].  To say that
| it "most likely" does something is basically the same as saying 
| "I {didn't bother to | couldn't} understand the code, but here's a
| wild guess", except that it's not quite as honest.
| 
| For the benchmark in question, Van Roy posted both the C and the Prolog
| sources, so it's easy to verify whether or not there's any table lookups
| going on.  There isn't.

No, there is no *explicit* table lookup in the prolog version of the
benchmark, but that doesn't mean that there is no table lookup of
cached results going on in the depths of the Prolog implementation.
It would be a valid thing to do in a Prolog implementation to speed up
unification.

It is quite easy to follow a C program and see what is going on, since
there is a good correspondance between the language and the hardware.
For Prolog, however, (like Smalltalk, ML, etc.) there is usually
quite a lot hidden in the implementation that prevents a direct
comparison.

The argument here is that "unification result cacheing" changes the
benchmark significantly -- entire call trees are pruned from the
execution.


	-- Tim Olson
	Advanced Micro Devices
	(tim@amd.com)