Risc vs Symbolics (was: Poor Sun timings, as competition...)

[p2@Porter.ASL.dialnet.symbolics.com (Peter Paine)]

    Date: Tue, 14 Aug 90 04:34 EDT
    From: RWK@fuji.ila.com (Robert W. Kerns)

	Date: Mon, 13 Aug 90 16:50 EDT
	From: Reti@riverside.scrc.symbolics.com

	    I know that real users compare whole systems (i.e. hw+so+compiler+env.+...)
	    [...]

Some people seem to have the misfortune to spend vaste amounts of lisp
time compiling large systems, whilst others spend their time researching,
experimenting, simulating, inferencing, modeling, interfacing, searching,
emulating, engineering etc.

It is impossible to make a benchmark that shows how powerful a system is
in such a way as to relate to the way that different people might use it. 

Is the question begged, given todays RISC cpu cycle rate, Lisp Machine
Lisp's special needs and the state of Ivory now; if time and money were
not object, could full Genera run faster on "standard hardware" than on
Ivory - and "faster" ought to be at least an order of magnitude.

Some years back, whilst reviewing such things as Gabriel's tests I
remember seeing that PSL running on a Cray 1, with integer only arith'
and no disk access, managed at best 10 times the performance of a 3600.
A figure that the new Ivory about covers.

Meanwhile, my 3600 with Eagle disks still matches the performance of
everything other than the XL1200 for the coding, compiling, evaluating,
debugging cycle on mountains of spagetti code.

The final rub seems to be the insatiable need people (even the most
level headed technical and business people) have for something new and
glamorous. I suspect that if the label of the XL1200 said Cray, many
Sunaholics would be drooling for it.

	Reti@Riverside.SCRC.Symbolics.COM =>
	[...]
	However, the Lispm hardware is a stack-based machine and is spending some amount
	of cycles pushing and poping arguments that would be held in registers on a
	traditional-architecture machine, so you'd get a benefit there, especially in
	arithmetic-intensive code.  (There was a register-based hardware project within
	Symbolics which would have addressed this problem but which was cancelled; during
	that project many of the group members wrestled with some of the same issues
	I'm discussing here, and ended up retaining most of the hardware help for the
	Lispm-specific features.)
	[...]
Are any of the people who worked on this project still available to let
the community know what they discovered?