Your timing worries, and generality

[Jon L White <JONL at MIT-MC>]

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

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