Re: inline array refs?

[lgm@polaris.ih.att.com (Lawrence G. Mayka)]

In article <9405131430.AA01635@cambridge.apple.com> bill@cambridge.apple.com (Bill St. Clair) writes:

   At 10:14 AM 5/13/94 +0000, Karsten Poeck wrote:
   >I translated some code to test iterative repair alogirithms from c to LISP.
   >The code mainly does fixnum operations and simple-array accesses. By adding
   >appropriate (the fixnum ...) and (declare (type (simple-array fixnum (*))
   >array)
   >I managed to get about half the speed of the corresponding c program
   >compiled with MPW on the same mac.
   >
   >The disassembly of the code shows calls to subroutines
   >(jsr_subprim $SP-GETLONG) and
   >(jsr_subprim $SP-MKLONG)
   >
   >I suspect that these calls slow down the programm. Does anybody know what
   >these routines do and how I could avoid them? I always thought that adding
   >enough declarations to a MCL program would give me the same speed as a
   >corresponding c program.
   >
   >Anyhow I tried to run the same program under LIspWorks 3.2 on a Dec-Alpha
   >and to my surprise a quadra 650 was more than two times faster than the
   >alpha, even after declaring fixnum-safety = 0. From looking at the
   >disassembly I suspect that the arefs are not inlined in LispWorks. Does
   >anybody know how I could get LispWorks to inline the arefs too?

   I don't know how to inline arefs in LispWorks, but I can help with
   your MCL problem. In MCL, an array that is declared to have fixnum
   elements is upgraded to have (signed-byte 32) elements. Since these
   can be bignums, the code is calling $sp-getlong to convert the
   untagged value from the array to an integer. To get rid of the
   $sp-getlong call, use a simple-vector, i.e. a simple-array with an
   element type of T:

LispWorks has this same implementation characteristic.  Make and
declare your vector to be SIMPLE-VECTOR, and you should see almost an
order-of-magnitude speedup.

I suggest that vendors instead define an array element type FIXNUM or
(SIGNED-BYTE 30) which just happens to be implementationally identical
to T.  Element types from (SIGNED-BYTE 17) to (SIGNED-BYTE 30), and
from (UNSIGNED-BYTE 17) to (UNSIGNED-BYTE 29), should upgrade to
FIXNUM; only beyond those byte sizes should upgrade to full 32 bits
occur (with its concomitant bit-shifting and bignum-checking).  This
scheme fits within ANSI Common Lisp rules but still makes the maximum
use of simple word-copying.

Otherwise, naive users who are accustomed to declaring arrays of
FIXNUMs will get an unfavorable view of the implementation's
optimization capabilities.
--
        Lawrence G. Mayka
        AT&T Bell Laboratories
        lgm@ieain.att.com

Standard disclaimer.