A mystery with slot access in LW

I got interested in performance of access to slots for not-very-good reasons, so I wrote some things to measure it.

The code I'm measuring here looks something like this:

(defclass a ()
  ((i :initform 0 :type fixnum)))

(defmethod svn ((a a) n)
  (declare (type fixnum n)
           (optimize speed (safety 0)))
  (dotimes (i n)
    (incf (the fixnum (slot-value a 'i)))))

And then I am measuring 100 calls to SVN with an instance of A, and N being 1000000, and then dividing the time by 2E8 (a read and a write for each loop step).  SVN is called once with the same instance and N=1 before this just in case things need to be compiled on the fly.

I'm measuring a bunch of other things too, but this is the interesting one here.

Here is (the start of) a report from the start of one run of this:

* LispWorks 8.1.2 on arm64 E
- Raw fixnum
  fixnum increment                                   1.59E-10s r= 1.0    
- Fixnum slot access
  slot-value (slot declared fixnum)                   3.90E-9s r= 18.    
  slot-value (no type)                                3.89E-9s r= 18.    

the r values are ratios between this and the fastest of its group, which in this case is struct slots (or car / cdr, which are as fast).  The 'raw fixnum' case is just incrementing a fixnum in a variable, and it's there to show the loop overhead and actual cost of incrementing the value is not large.  The 'no type' line is for another class without the type specification for the slot (makes no difference of course).

So, OK.  Here is another run of the same code, same machine:

* LispWorks 8.1.2 on arm64 E
- Simple fixnum.
  fixnum increment                                   1.59E-10s r= 1.0    
- Fixnum slot access.......
  slot-value (slot declared fixnum)                   1.78E-8s r= 84.    
  slot-value (no type)                                1.77E-8s r= 84.

This about half an order of magnitude slower.

To produce the second report I:

- started LW (command line, no multiprocessing)
- compiled the file
- loaded the file

To produce the first report I ... have no idea what I did.  Sometimes it is fast, sometimes it is slow.  Sometimes recompiling & reloading makes it fast, sometimes it makes it slow.

It is a mystery.

--tim

(I have a working theory developed over many years: CLOS is infested with hippies, and everything about it therefore depends on things like how many beads you are wearing and whether you have recently consumed any illicit substances.  This theory originated in the late 80s: we had a number of D machines, which were entirely strange machines.  They were all the same.  Except one: it was the same, but it was about 10% faster than all the others.  You could move any board from it into one of the other machines and both would then be slow.  What made it faster was some kind of spirit living inside that particular collection of hardware.

Well, CLOS is also a west-coast product, of course.)


_______________________________________________
Lisp Hug - the mailing list for LispWorks users
[email protected]
http://www.lispworks.com/support/lisp-hug.html