Re: More on Lisp structures performance

> On 22 Jan 2026, at 16:41, David McClain <[email protected]> wrote:
> 
>> 3. … but even the latter still won’t match performance of native code generated by C (or SBCL for that matter) and that does not have anything to do with some magical obscure compiler quirks and tricks.
>> 
> 
> Puzzling language here…  can you elucidate? 

This is what was supposed to be covered in the ‘another' email, but in short, there is fixnum and array indexing overhead in LW that one cannot get rid of, by the look of things. That is not present in C altogether, and SBCL apparently has ways to switch to raw types on high levels of optimisation, this is how its compiler seems to consistently blow LW out of the water by substantial margin regardless of the tricks used.

The mechanics of using fixnums internally for everything is hard wired into LW’s compiler and it is not possible to override that, at least by the means of the public API. This is basically the gist of why SBCL is always faster as it apparently can operate on raw data types internally. LW can’t. This is not a problem in many cases, but is a serious issue when doing array indexing.

In other words, you can have good performance on the modern gear in LispWorks (I have just done a test where it has summed 3B integer values in a second, one cycle per summation in a tight loop in other words) but sadly you won’t get the top performance in anything that involves processing arrays of data (pretty much all numeric code, in other words). For that you would need to switch to SBCL once you have done prototyping in LW, or rewrite hot spots in C and use FLI.

For non-numerical code, symbol list processing, expert system inference and the likes it should do as well as anything else, really.

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