Nikodemus Siivola

MAKE-INSTANCE optimizations

Mon, 29 Jun 2009 11:50:09 +0300

SBCL has always had a fairly efficient MAKE-INSTANCE -- as long as the class argument is a quoted symbol and all the keywords in initargs are constant as well.

This is due to what are called ctors. Very briefly, a call such as

(make-instance 'point :x x :y y)

is transformed into something along the lines of

(let ((#:ctor (load-time-value (ensure-ctor 'foo :x :y))))
  (funcall #:ctor x y))

where CTOR is a funcallable instance. The first time it is called, an optimized constructor is generated, saved as the funcallable instance function, and finally called with the provided arguments. Later calls get the optimized constructor ready made.

There are multiple efficiency gains here: initargs can be checked for validity at compile time, and (assuming certain things hold true about the metaclass of the class and its methods) essentially the whole MAKE-INSTANCE -> ALLOCATE-INSTANCE | INITIALIZE-INSTANCE -> SHARED-INITIALIZE call tree can be open coded, and slot accesses can be performed using STANDARD-INSTANCE-ACCESS with constant slot locations. This all works with class redefinitions as ctors are updated automatically.

Unfortunately, this made the performance of non-constant class arguments to MAKE-INSTANCE extremely unattractive in comparison: 10-100 times slower is fairly typical. Ouch!

At ELS 2009 Didier Verna asked if we could do something similar for the non-constant case as well. Turns out we can:

(make-instance class :x x :y y)

can become something like

(let* ((#:cache (load-time-value (cons 'ctor-cache nil)))
       (#:store (cdr #:cache)))
  (multiple-value-bind (#:ctor #:new-store)
      (ensure-cached-ctor class :x :y #:store)
    (setf (cdr #:cache) #:new-store)
    (funcall #:ctor x y)))

where the ctor corresponding to the class argument is first looked for in the cache: if it is not found a new one is generated and cached.

This was implemented in SBCL 1.0.29.41; now the non-constant class arguments performs much better, being roughly only 1.15-1.25 times slower than the constant ones. Hopefully this will make a real difference in some applications out there!

A bit later another ctor optimization improvement was implemented, improving cases where the full open coding could not be done due to defined methods, but where we are still able to check initargs at compile time and replace the MAKE-INSTANCE generic function call with a slightly faster normal function call to a simplified constructor function: this makes such calls 4-10 times slower than the fast path, but still considerably faster than the worst case scenario.

The message to take home is actually not about SBCL optimizations -- as much as I like to talk about them: I think ctors are an excellent example of compiler macros doing inline caching and specialization. A nice technique that could probably be used more often than it is.

Note: SBCL inherited its ctor optimizations from CMUCL: they are the work of the estimable Gerd Moellmann. Things described above do not replace his work, just extend it around the edges. Those interested in the gory details can look at src/pcl/ctor.lisp in the SBCL source tree.

Vim and SBCL

Sat, 6 Jun 2009 00:36:28 +0300

Disclaimer: I don' use vim. However, there was a question on sbcl-devel about how to make ED use the console vim, and I thought someone not on sbcl-devel readers might get a kick out of this:

(require :sb-introspect)

(define-alien-routine system int (command c-string))

(defun namestring-for-vim (thing)
  (when thing
    (typecase thing
      (pathname
       (native-namestring (translate-logical-pathname thing) :as-file t))
      (string
       thing)
      (t
       (let* ((source
               (sb-introspect:find-definition-source (fdefinition thing)))
              (pathname
               (sb-introspect:definition-source-pathname source))
              (offset
               (or (sb-introspect:definition-source-character-offset source)
                   0)))
         (unless pathname
           (error "Don't know where the definition of ~S is, sorry." thing))
         (format nil "-c \"goto ~A\" ~A"
                 offset
                 (namestring-for-vim pathname)))))))

(defun ed-in-vim (thing)
  (system (format nil "vim~@[ ~A~]" (namestring-for-vim thing))))

(push 'ed-in-vim *ed-functions*)

Given this, (ED 'CONS) does the right thing, assuming SBCL sources are in place.

Condition Style Guide

Wed, 3 Jun 2009 14:18:58 +0300

I don't claim this to be authoritative, but I'd be very interested in hearing any opposing views. So: a quick style guide for using the Common Lisp condition system -- I'm eliding restarts for now, though.

Signalling Conditions

Use #'ERROR to signal conditions inheriting from SERIOUS-CONDITION. This includes all subclasses or ERROR. SERIOUS-CONDITION is a convention that means "this will land you in the debugger if not handled", which is what #'ERROR ensures.

Inherit from ERROR if unwinding from the error leaves the system in a consistent state. Subclasses of ERROR mean "oops, we have a problem, but it's OK to unwind."
Inherit from SERIOUS-CONDITION, not ERROR, if the system is messed up somehow, and/or requires either human intervention or special knowledge about the situation to resolve: SERIOUS-CONDITIONs that are not ERRORs mean that "something is deeply wrong and you should know what you are doing if you are going to resolve this."

Use #'WARN to signal conditions inheriting from WARNING. This includes all subclasses of STYLE-WARNING. WARNING is a convention that means "this will print out a warning if not muffled, and you can muffle this with the MUFFLE-WARNING restart", which is what #'WARN ensures.

Inherit from STYLE-WARNING if muffling the warning should be fine pretty much whenever.
Inherit from WARNING, not STYLE-WARNING, if muffling the warning is OK only if the muffler knows how to deal with the specific warning: otherwise someone should be made aware of the situation, which is what warnings are for.

Otherwise use #'SIGNAL, and don't expect others to handle your conditions unless you document them as part of your API.

Handling Conditions

Learn the difference between HANDLER-BIND and HANDLER-CASE. Short version: HANDLER-CASE always unwinds, with HANDLER-BIND you can eg. log the condition without handling it, or decide whether to unwind or not after inspecting the condition in more detail.

Don't handle arbitrary conditions: a lower layer using #'SIGNAL as a communication mechanism will break if you do that.

Don't muffle arbitary WARNINGs that are not STYLE-WARNINGS. A full warning can still be muffled, but only if it's one you know to be harmless in your case. Otherwise, a full warning should either result in a fail-stop, or logging the condition somewhere -- depending on the kind of application you are developing.

Don't handle arbitary SERIOUS-CONDITIONs that are not ERRORs: if you cannot pop up a debugger and don't know exactly how to deal with this specific condition, the right answer is to crash -- of course preferably with an error message, but don't expect that to work properly: maybe the serious condition was about corruption in the IO system...

If you just want to ensure the application doesn't enter the debugger, bind *DEBUGGER-HOOK* appropriately -- but be aware that #'BREAK circumvents *DEBUGGER-HOOK*: if that's a danger, refer to the documentation of the implementation you are using -- most provide a way to hook into #'BREAK.

Happy hacking.

Performance, Benchmark of the Day

Tue, 2 Jun 2009 11:56:36 +0300

In reference to The Price of Abstraction and the associated Reddit comments:

On my laptop C++ versions 1 and 2 run in 2.139s and 2.410s respectively (user+sys), and the direct Common Lisp translations using double floats and native complexes run in 3.692s and 4.594s on SBCL. See: mandelbench.lisp

I haven't investigated the source of the performance difference, but given that the SBCL generates -- at a quick glance -- reasonable looking code for both, I believe the difference comes from something lacking in loop optimization, and/or possibly suboptimal floating point instruction sequences. Given that Paul Khuong is working on using SSE2 for complex arithmetic, it will be interesting to see what kind of effect that has on performance.

I did not bother implementing complexes as user-defined objects -- depending on how you view this benchmark it either invalidates my numbers, or focuses on the only real point there is...

Conclusions?

While not hitting the C++ target today, I think these numbers support SBCL's call to fame as a high-performance Common Lisp compiler.

Also, an important reminder for any CL advocates: when comparing the speed of a Common Lisp implementation like SBCL to C or C++, never say Common Lisp is faster -- not even in those cases when it is. Everything most performance oriented people know conflicts with that, so that even if you are right, they will not believe you. Instead, say something like: "Even for low level number crunching SBCL can generate code that approaches gcc or g++ in speed.", or whatever the point you are trying to make is. Say almost as fast, not faster -- and please, don't lie. Nothing is worse PR then unfounded claims.

As a bonus, some interesting -- and related -- papers from Didier Verna "On Behaviour and Performance of Common Lisp": Beating C in Scientific Computing Applications, and CLOS Efficiency: Instantiation.

ELS 2009

Mon, 1 Jun 2009 20:58:47 +0300

Milan was hot, and the campus quite confusing -- but the symposium itself was very good.

Given that ELS 2008 netted ~50 registrants, the 45 who showed up this time seem a clear success to me, given both the ILC earlier this year and the general state of the econony the world over.

Talks and papers: mostly quite interesting! Particular highlights for me personally were Thomas Burdick's paper on compiling FEXPRs, and Pascal Costanza's on a hygiene compatible macro system for Common Lisp.

About the latter: I'm fairly sure that gensyms could be used for aliases instead of interned symbols, since in case of locals the externalization does the right thing, and for global names one can use (SYMBOL-VALUE 'FOO) etc as aliases. Moreover, it appears to me that it would not be particularly hard for the compiler to provide aliases implicitly -- making a hygienic macro system that integrates nicely with vanilla CL a relatively simple matter. Cool stuff.

On an unrelated note, I think many people who were around for the ANSI standardization process have a distinctly different view of Common Lisp than those who came in later: the first group of people have a tendency to see it as a historical accident were they didn't get some things right -- whereas I (and I believe many others too) see CL as something that did get many things right. These aren't mutually exclusive of course, but is a different emphasis.

DEFGLOBAL in SBCL

Fri, 22 May 2009 16:37:37 +0300

I recently added support for global variables in SBCL: they cannot be rebound or made unbound, which are occasionally useful semantic properties.

More importantly, however, they are an efficiency measure for those cases when a threaded application is using a special as global variable -- never rebinding it: on threaded builds special variable lookup has a fair bit of overhead: in addition to normal boundness checking the system also needs to check for the thread-local binding. Using a global instead allows just grabbing the value slot of the symbol:

(defparameter *foo* 0)
(defparameter *foo2* 0)

(defun foo (n)
  (declare (fixnum n))
  (dotimes (i n)
    (setf *foo* *foo2*)
    (setf *foo2* *foo*)))

(defglobal **bar** 0)
(defglobal **bar2** 0)

(defun bar (n)
  (declare (fixnum n))
  (dotimes (i n)
    (setf **bar** **bar2**)
    (setf **bar2** **bar**)))

(time (foo 100000000))
(time (bar 100000000))

FOO takes 0.55 seconds of run time, and BAR 0.37 -- about 30% difference in favor of global variables.

It needs to be taken into account, however, that this is an extremely artificial benchmark. Eg. doing bignum arithmetic in the loop loses the difference between specials and globals into noise, so gains for real applications are likely to be much smaller -- and almost certainly nonexistent for a large class of applications.

Secondary effects due to reduced code size are possible, however. This is what assignment from *FOO2* to *FOO* (both special variables) looks like:

;      1E2: L0:   8B05A8419E11     MOV EAX, [#x119E41A8]      ; '*FOO2*
;      1E8:       8B5011           MOV EDX, [EAX+17]
;      1EB:       64               FS-SEGMENT-PREFIX
;      1EC:       8B12             MOV EDX, [EDX]
;      1EE:       83FA5A           CMP EDX, 90
;      1F1:       7503             JNE L1
;      1F3:       8B50FD           MOV EDX, [EAX-3]
;      1F6: L1:   83FA4A           CMP EDX, 74
;      1F9:       7464             JEQ L8
;      1FB:       8B35AC419E11     MOV ESI, [#x119E41AC]      ; '*FOO*
;      201:       8B4611           MOV EAX, [ESI+17]
;      204:       64               FS-SEGMENT-PREFIX
;      205:       83385A           CMP DWORD PTR [EAX], 90
;      208:       7405             JEQ L2
;      20A:       64               FS-SEGMENT-PREFIX
;      20B:       8910             MOV [EAX], EDX
;      20D:       EB03             JMP L3
;      20F: L2:   8956FD           MOV [ESI-3], EDX

Contrast and compare with assigment from **BAR2** to **BAR** (both globals):

;      A18: L0:   8B15CC69A211     MOV EDX, [#x11A269CC]      ; '**BAR2**
;      A1E:       8B52FD           MOV EDX, [EDX-3]
;      A21:       8B1DC869A211     MOV EBX, [#x11A269C8]      ; '**BAR**
;      A27:       8953FD           MOV [EBX-3], EDX

Hopefully there are users out there who find this of use! To me at least they seems like a natural match for locks, for example.

Array Improvements

Mon, 18 May 2009 10:55:39 +0300

I've just about completed a slew of array related optimizations in SBCL. Since the details are not all that interesting, I'll focus on couple of my favorite changes:

MAKE-ARRAY already had some compiler transforms that were able to take care of some aspects of it, but there were some IMO perfectly idiomatic cases that were dog slow:

;; the compiler didn't realize it could elide the call to LIST and use
;; it's arguments directly to initialize the array -- ditto for VECTOR
;; and backquoted forms in place of LIST.
(defun bar (x y z)
  (make-array 3 :initial-contents (list x y z)))

Previously this resulted in consing up the list at runtime, and then making a full call to MAKE-ARRAY, including keyword argument parsing and everything. I'll spare you the disassembly -- pick up an pre 1.0.28.51 SBCL and see for yourself if you must.

Now, we are instead able to transform the above into something like this:

(lambda (x y z)
  (initialize-vector (allocate-vector ...) x y z))

..which in turn is open coded, resulting in an almost 90% speedup. If you were aware of this deficiency, and used explicit (SETF AREF) to initialize the array, you were manually doing what the compiler now does automatically -- and will not see any performance improvements.

What's more, now we are also able to stack allocate arrays in the presence of :INITIAL-CONTENTS or :INITIAL-ELEMENT, including those allocated with a call to VECTOR.

FILL also now benefits from a better transform. If the array element type is known (and fills a bunch of criteria), we are able to fill much more efficiently by using "bit bashing". The implementation functions for this have existed in SBCL for quite a while now, thanks to Nathan Froyd, but were not used until now.

Consider eg. an array with element type (UNSIGNED-BYTE 8). By first filling a word with 4 (8 on 64 bit platforms) copies of the initial element, we can fill the array a word at a time -- poor man's SIMD, if you will. This strategy was already used for filling bit vectors, but now it applies to all types where it is safe.

Upshot: upto 90% faster FILL.

New lisp book by Barski available for preorder

Thu, 30 Apr 2009 14:57:04 +0300

I'm not sure if this is the "new O'Reilly lisp book" that some have been hinting at, but coming later this year is Land of Lisp, Learn to Program in Lisp, One Game at a Time! by Conrad Barski. I'm guessing the O'Reilly book is something different, as this has "No Starch Press" as the publisher, unless that's a subsidiary of O'Reilly or something.

Getting a Grip, Finally

Wed, 11 Feb 2009 14:01:00 +0300

Turns out I didn't even know how to hold a sword... Yesterday, while making notes about monday's class I wrote down something like "Posta di bicorno: flat supported by the palm."

I started wondering about that, since it seemed very much like the regular grip to me. A moment with sword in hand confirmed that yes, for me the flat was indeed always supported by the palm, and edge by almost nothing but the crotch of the thumb. Oops.

I fiddled with the grip, and ended up with something that felt reasonably ergonomic, and had the edge better supported. Later, during class yesterday, I asked about this, and got the confirmation that my old grip was indeed bogus. Cutting drills immediately revealed the new grip as superior: I have the tendency to hyperextend my dominant arm when cutting into posta longa, which was much reduced with the corrected grip.

Looking back, I suspect a major reason for the palm-on-flat grip I used was the extremely flat and wide handle on my old Lutel, which makes the palm-on-flat grip fairly tempting, but also makes the wrong grip less obvious visually:

Oh well. I wonder how long it will take to unlearn this bad habit...

Back to the Salle

Sat, 7 Feb 2009 14:37:03 +0300

I started fencing at the SESH in the autumn of 2001. I loved it. For two or three years I trained with great vigor and enthusiasm.

Then "things happened", and my training tapered off. I was no longer going to the salle regularly. Finally it came to me that I didn't remember the last time I trained or know the next time I would. I wasn't training anymore.

I missed the training, the salle, the people. I missed everything. By the time I had been away for maybe a year, I started making abortive attempts to get back into training. Every time things tapared off again. A few months or year later I would try again -- and nothing ever came of it.

Last summer I decided that if I don't manage to get back into groove this time, then it would be the last time I tried. Time to do or die. I was getting tired of failing to do something I liked. Guess what happened? I went to the salle maybe three times, had a great time, and ... that was that.

Over the following months I started to miss fencing again.

A lot of people drift from one martial art to another. I know I have -- from judo to modern archery to jujutsu to taijutsu to historical fencing. While I was getting worked up about missing training I started wondering if I should do something else instead? There's a reputedly decent savate salle a couple of blocks from where I live -- maybe I should check it out?

But I didn't want to do savate, I wanted to fence!

It took a me while to see it, but I was thinking about switching because faced with a new thing I would not be comparing the current me against a past and vastly superior me. As a bonus, on a beginner's course a poor physical condition is relatively commonplace. It seemed like an easier way forward -- which was a perfectly ass backwards way to think about it.

When I fenced, I did it for its own sake, not to reach some imaginary signpost like "my previous level". No wonder my attempts at getting back into training were failing. I was missing the forest for the trees, feeling frustrated with myself instead enjoying what I was doing right then and there.

I still worried: I try to keep the promises I make to myself, and I had given myself an ultimatum the last time I went back to salle. Was I going back on that now? Finally I overruled my earlier decision as misguided nonsense: it doesn't matter how often you fail in something like this, where the worth is in the action itself.

At this point the next step was obvious: I enrolled into the next beginner's course at SESH.

(In the image above is my new favorite toy, a Pavel Moc Embleton. Quite lovely, and much lighter to handle than my old Lutel.)