Re: A slightly surprising and good thing
"Yuri Davidovsky (as work at disclosure dot ie)" <[email protected]>
| Newsgroups | gmane.lisp.lispworks.general |
|---|---|
| Message-ID | <[email protected]> |
> On 24 Mar 2026, at 14:49, Tim Bradshaw (as tfb at tfeb dot org) <[email protected]> wrote: > > Obviously the last digit is meaningless here. What was pleasing is that for this case LW is not slower than SBCL at all. It does much less well if safety is not 0 whereas SBCL obviously manages to convince itself of enough things that it can elide checks anyway. I am curious why SBCL is not faster here. The problem with LW is that every array access in it has some baked-in overhead, for which I haven’t found a way to work around: 1. The array index is always a fixnum in LW. That means that it has to get detagged on each array access. Even if you are using 8 byte alignment (as you would for a typed double-float array), which nicely translates to the 000 tag for fixnums (meaning you do not really have to detag it to access 8 byte aligned values), it still does this detagging operation. +1 cycle of overhead. 2. LW does not store the offset into the array’s payload in a register but rather skips the 8 byte header on each array access every time, by additionally incrementing the array's index by 8. +1 cycle of overhead again. The fact that you matched the performance of SBCL probably means that it does the same, or the SBCL code wasn’t as optimised as it could be. As I understand it, SBCL can use raw values for array indexing, by keeping a little table for the GC telling it which register values are raw, so it does not knock itself out by accident, but I am not familiar enough with SBCL to be sure if that is in fact the case. _______________________________________________ Lisp Hug - the mailing list for LispWorks users [email protected] http://www.lispworks.com/support/lisp-hug.html