Re: Unboxed structures (yes, again, only this time for real)
Martin Simmons <[email protected]>
| Newsgroups | gmane.lisp.lispworks.general |
|---|---|
| Message-ID | <[email protected]> |
>>>>> On Fri, 16 Jan 2026 19:46:27 +0100, Yuri Davidovsky (as work at disclosure dot ie) said: > > > 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? 1 word for the GC to use and 1 word to identify the Lisp type of the structure. > >> 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. The tagging/detagging of single-float is quite fast and might be lost in the noise of the memory accesses if this was test that accesses many megabytes. -- Martin Simmons LispWorks Ltd http://www.lispworks.com/ _______________________________________________ Lisp Hug - the mailing list for LispWorks users [email protected] http://www.lispworks.com/support/lisp-hug.html