[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Timings for the BITS emulations in MacLISP
- To: GJC at MIT-MC
- Subject: Timings for the BITS emulations in MacLISP
- From: Jon L White <JONL at MIT-MC>
- Date: Mon, 26 Oct 81 16:44:00 GMT
- Cc: BUG-LISP at MIT-MC
- Original-date: 26 October 1981 11:44-EST
Date: 25 October 1981 13:48-EDT
From: George J. Carrette <GJC at MIT-MC>
Subject: Joke of the century.
The implementation of strings and bitvectors in Maclisp is a joke.
I brought up the NIL READer in maclisp to use as a Macro32 parser,
and the damn thing runs 138 times slower than it does in real VAX NIL.
If it were only 2 times slower it would be usable, but 138 times,
that is absurd. For a 297 calls to +TYI there were 1297 calls to
SI:CHECK-TYPER, 936 calls to PTR-TYPEP, 936 calls to BITSP, . . .
Your failed to mention whether or not you ran your timing tests with
*RSET on or off. This makes a big difference for the emulation code --
remember, PDP10 doesn't have load-byte-indexed instructions, nor general
variable-length bit-field hacking, and these data types and primitive
operations were designed with an architecture in mind more like the
VAX or 370 than the PDP10.
The emulation packages were designed to check all types of arguments,
and try to be "secure", so setting *RSET to () should give an
inordinate speed-up. More to the point, if you know what you're
doing, you can use the low-level functions +INTERNAL-CHAR-N and
+INTERNAL-RPLACHAR-N instead of CHAR and RPLACHAR for another large
speedup. Still, none of these are likely to be "open-compiled"
for the PDP10, since the basic targeted instructions just aren't
in the PDP10 repetoire.