Re: Lisp_Marker size on 32bit systems

[Stefan Monnier]

>> I still wonder why it would be slower at all.
> My guess is cache effects. My processor has a cache line size of 64 bytes,
> so if objects are allocated in 32-byte chunks they won't straddle cache
> boundaries and code will be less likely to thrash the cache.

The difference of alignment is between multiples-of-8 and
multiples-of-16, and allocation is done by the vectorlike code, so
I think 32 byte objects aren't supposed to be much more likely to be
aligned on 32 byte boundaries than on 32B + 16B.

Hence, I don't find your argument very convincing.

> I ran this benchmark in the 'lisp' subdirectory:
> EMACSLOADPATH= perf stat -dd
> '../src/emacs' -batch --no-site-file --no-site-lisp --eval '(setq
> load-prefer-newer t)'  -f batch-byte-compile org/org.el
>
> and am attaching the results for the 24-bit allocation (a bit slower) and
> the 32-bit allocation (a bit faster), and they are in line with this guess.

Those perf-stats also show improved I$ performance, which isn't
explained by your suggested explanation.  Similarly, they show a reduced
number of instructions.

IOW, I think there's something else at play than just the cache effects.

>> it's not clear what the extra tags would be useful for.
> Presumably to help performance elsewhere.  Admittedly I'm blue-skying
> a bit here.

I think a 16 byte alignment could indeed be a good idea on 64bit systems
(assuming we make the tags take advantage of it), but on 32bit systems
where the memory is usually more constrained to start with, I think it
would be a mistake.


        Stefan