Re: Lisp_Marker size on 32bit systems

[Stefan Monnier <monnier@IRO.UMontreal.CA>]

>> Where does this 20% slow down come from?
> Ha! It was because the 16-byte alignment caused pure space to overflow,
> which disabled GC.  No wonder there was such a big performance difference.

OK, that makes more sense.

> I fixed that, and now the patch to shrink marker allocations from 32 to 24
> bytes on x86 causes my standard benchmark (make compile-always) to run only
> 1.0% slower, which is more reasonable.  A microbenchmark of running
> (make-marker) over and over again for 10,000,000 times runs 36% slower (815
> vs 597 ns for a single call).

I still wonder why it would be slower at all.

> Maybe we should be using 4 mark bits instead of 3?

On 32bit systems, both cons cells and float cells use 8 bytes each, so
aligning on multiples of 16 would double their memory use.

And we currently have one free tag, so not only would using 4 tag bits
significantly increase memory use for those objects, but it's not clear
what the extra tags would be useful for.  Also with the bignum support,
the pressure to maximize the size of our fixnums is much lower, so we
could even consider using fewer Lisp_Int tags if we feel like we need
more tags.

FWIW, IIUC XEmacs uses a 2bit tag which simply distinguishes between
Lisp_Int0, Lisp_Int1, Char, and other objects.  Since we don't have
chars, that's like using a single-bit tag for us.

Maybe we should introduce some way to instrument
SYMBOLP/STRINGP/VECTORP/MARKERP/CONSP/... in order to try and figure out
which objects are more deserving of having their tag right there in the
Lisp_Object rather than just in the vectorlike_header.


        Stefan