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

[Reti@Riverside.SCRC.Symbolics.COM]

    Date: Mon, 13 Aug 90 10:03:56 +0200
    From: mdc%libeccio.TECSIEL.IT@CUNYVM.CUNY.EDU

[Disclaimer]
These remarks are my own personal opinion, not necessarily the official positionb
of Symbolics Inc, my employer.

    I know that real users compare whole systems (i.e. hw+so+compiler+env.+...)
    but i was wandering if someone has tried to answer to the following
    (silly) question:
I don't think it is a silly question.

    Suppose to write a RISC (for example SPARC) code generator for the
    Symbolics Compiler (and to write all the needed hardware specific
    run-time), and then to compile the *WHOLE* Genera on a RISC
    Workstation.

    I suppose it should be possible, isn't it ? (don't care the
    development costs, it is just an hypothesis).

Yes, I believe it is possible (Turing equivalency and all that); however, the
crux of the issue is the development cost (and support costs afterward).

    How the result would compare to the original Genera on a Symbolics?

Depends upon how you went about it, see below.  I believe you could get exactly
the same functionality.  The performance is dependent upon both the speed and
exact packing of functionality into the RISC instructions.

    (Be fair: consider enough amount of core memory, and machine of the
    same generation; consider a UNIX workstation or a bare workstation as
    you need it).

I'm considering only a bare workstation, since one of the features of Genera I
use the most is the ability to instrument and change (often dynamically per
context switch!) what would be operating system code and inaccessible under
Unix.

The hardware that Genera runs on was designed to make certain combined
operations efficient by doing them in parallel (e.g. type checking + arithmetic,
checking for forwarding-pointer/oldspace reference + memory reference, matching
up required and supplied arguments for common lisp functions, hashing for method
dispatch, bounds-checking + array reference etc.).  If you implement those exact
same semantic operations in a typical RISC machine instruction set, they could
not occur in parallel and therefore would run slower when counted as number of
cycles.  To come out even, the cycle time of the machine would correspondingly
have to be some number of times smaller than the current Ivory cycle time (65 ns).
	  
The exact average factor depends on many things, but primarily upon the
architecture you design for the virtual memory representations in the RISC
machine and how well the functionality of the pre-packaged RISC instructions
maps into the low level operations you have to perform.  For example, if you
can test for both a forwarding pointer and an oldspace pointer at the same
time, you'd be much better off than if you had to test them separately.
In the former case you might add only two cycles to every memory reference,
in the latter it would be four.

Unfortunately, the factor is likely to be very different for different
operations, so the dynamic run-time frequency of those operations would
determine the overall performance of the machine.  Genera makes heavy use
of features that are likely to be expensive on other machines precisely
because we designed them to be cheaper on our hardware.

My gut feel is that you'd need at least a factor of 3 and 4 to break
even, though you'd have to do the architectural design and then code up sample
frequent instruction sequences and sum their timings to be sure.

Also, the storage of tags is a problem; if you want 32-bit integers and floating
point numbers, but also want tags, you must have either a word size bigger than
32 bits (Ivory has 40) or do some kludging around to simulate it which will no
doubt have a negative impact on the performance of most if not all memory
references.

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.)

If you are willing to turn off (partly or wholly) type checking, array bounds
checking, etc. you could get even more speed advantage, but this is a bad idea
in my opinion, as these features help catch problems nearer their source and
often mean the difference between difficulty and impossibility in quickly
tracking down hard bugs in complex, layered software systems.  If you do decide
to take this approach, since the bulk of Genera code has been designed to work
in a hardware type-checking environment it would take a large amount of work to
add the type declarations that would make it run efficiently.  Moreover, I feel
that the development and support costs for this type-declared Genera would rise
astronomically.  (I worked on traditional operating systems at DEC and it
is MUCH cheaper to enhance and maintain Genera.)



    __________      Maurizio De Cecco
    ___/  \___      Tecsiel S.p.A. (until end of August)
    ___\__/___      Via S.Maria 19
		    56100 Pisa - Italy


    email: mdc@tecsiel.it (or mdc%tecsiel.it@cunyvm.cuny.edu )
    phone: +39-(50)-512514
    fax:   +39-(50)-589015