Re: Unboxed structures (yes, again, only this time for real)
"Yuri Davidovsky (as work at disclosure dot ie)" <[email protected]>
| Newsgroups | gmane.lisp.lispworks.general |
|---|---|
| Message-ID | <[email protected]> |
> On 16 Jan 2026, at 16:14, Tim Bradshaw <[email protected]> wrote: > > The object in memory then usually has some header saying what it is followed by the value. Some special types don't have a header word (conses). Why do we have two words for a header in structures? >> Lisp is notoriously very loose on types and that alone does not say much to me personally without seeing some ground truth on the byte level. > > It's not very loose on types: no GCd language can get confused about types if it doesn't want to explode every once in a while. it is dynamically typed, and for instance the type option to structure fields may not be enforced (or change the representation), and the same goes for type declarations in functions &c. By “loose” I meant exact this situation, where you create a specialised array, but as the element type you get T. Or when you define a custom type by deftype but what you get is not really a data type. It doesn’t matter really. >> However it could be correct that the particle array was indeed an array of pointers. The reason why they were performing as fast as a contiguous array of custom structs could be because the structs themselves were [...] > > It is correct, yes. It seems to be the most plausible explanation that the structs were getting prefetched from the heap due to the fact that they were in a continuous block, so we were getting the same performance as the serialised struct array. The back of the napkin CPU cycle budget estimations also aligned nicely with observations so I now do not think that the typed aref access could be slower than it should be, otherwise the cycle counts would not add up. However, given that the values in the struct fields weren’t raw, why are we not seeing the tagging/detagging overhead compared to the serialised raw structs? That would be less than what it is for boxed values, but still. _______________________________________________ Lisp Hug - the mailing list for LispWorks users [email protected] http://www.lispworks.com/support/lisp-hug.html