Re: unboxed structure fields (or class slots)

On 7 Jan 2026, at 11:44, Yuri Davidovsky <[email protected]> wrote:
> 
> 
> This approach of using struct of arrays (rather than arrays of structs, or classes) is a common optimisation technique in high throughput applications, like games and graphics (think of particle animation), so you are not doing anything wrong here, it is an expected evolution, even in lower level programming languages. Working with unboxed values on an instance alone will likely not give you the best possible performance.

That's what I'm aiming at.  I wrote a thing which deals with 'structures' all of whose slots are (say) double-floats, and will write all the accessors etc for you, so the code looks like you're dealing with a vector of structures, but you're really dealing with a vector of double-floats (and the resulting code is both very quick and almost declaration-free which is nice).  I'm now feeling my oats and have been thinking about a more general thing where you'd define a 'structure' with slots of various types and it will write the accessors for dealing with the several underlying arrays.  I haven't spent much time on it yet though, and it's slightly suffering from second-system effect.

> 
> But the thing is, if we take OOP languages, class objects are passed by reference there typically, so even if they do hold numeric values in their raw form, you will have to deal with pointer lookups, which is less than ideal, boxed or unboxed. So yes, using packed arrays is the way to go in my opinion, regardless of whether you are using lisp, or C++.

I think so, yes.  In any language with strong object identity you can't have arrays of unboxed values in general (same goes for structures &c) at all.  CL conveniently relaxes object identity for numbers and characters so you can in those cases, which was a clever design compromise I think.

In an implementation which can store unboxed doubles in structure/instance slots (single floats are likely immediate in any 64-bit implementation and are in LW, so doubles are the interesting case really) then array-of-structs still means that for every element you follow a pointer, likely check the type of the object there, and then have access to its unboxed fields.  For an implementation which can't do that you do all that and in addition have to follow a pointer for each field access, and almost certainly cons a double for each store which is horrid.  SOA means none of this happens.

SOA is also what Fortran programmers would do, and thus The Right Thing.

--tim



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