[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Your timing worries, and generality
- To: GJC at MIT-MC
- Subject: Your timing worries, and generality
- From: Jon L White <JONL at MIT-MC>
- Date: Mon, 26 Oct 81 20:22:00 GMT
- Cc: BUG-LISP at MIT-MC
- Original-date: 26 October 1981 15:22-EST
Date: 26 October 1981 14:38-EST
From: George J. Carrette <GJC at MIT-MC>
But why a function call to get an element of a string? That is what
stinks. So, I changed the implementation, made my own strings that
used a HUNK of FIXNUMS, and got open coding and decent speed.
Originally, my STRING emulation package used hunks, but there are
severe limitations to that approach -- you certainly can't get
enough generality (or space efficiency) from this approach to do
most of the NIL system code already written (assembler, compiler,
text processor etc).
The same thing works like a charm for BIT1P ==>
(LOGAND (LSH 1 (\ J 36.)) (CXR (+ 2 (// J 36.)) X)).
This is sort of what happens with BIT1P now, except that a function
call has to be done in order to retrieve the bit from a FIXNUM
Speaking of function calls, the call to +INTERNAL-CHAR-N takes about
20 microseconds to retrieve a character from a string -- the
corresponding VAX retrieval has got to be at least 1 microsecond,
and possibly more (depending on whether the arguments have to
be moved to registers, etc). Thus even allowing your 'factor of 3'
for failure to set *RSET to (), *** and timing only this correspondingly
slow operation ***, its hard to imagine how you came up with a figure of
138. times slower on the PDP10. Could it be that there's something
else you're not telling?
Of course, BITS emulations may be slower since they aren't as
generally useful as STRINGs are -- the important thing was that
they be large enough to handle cross-compiled SUBRs, and using
hunks rather than FIXNUM arrays won't make it for the big cases.
Worse yet, the memory utilization factor is even more important
on the PDP10, and it is poor when you have to take a new page of
HUNKn space just because you wanted a single BITS of some random size.
Of reasonable importance is how often such programs will be run
on the PDP10 -- if it's a small number of times (as you suggest)
then virtually all your time spent developing alternative, less general
systems will be wasted. But if BITS are really important, and
if everyone agrees to limit their size by the hunk kludgery,
then a simple upward-compatible change can be done in the BITS