[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Proposal: block-based vector allocator

From: Dmitry Antipov
Subject: Re: Proposal: block-based vector allocator
Date: Fri, 01 Jun 2012 09:15:59 +0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1

On 05/31/2012 07:43 PM, Paul Eggert wrote:

Have you done some performance analysis on typical 64- and 32-bit hosts?


Has this been published somewhere?  Should be in the ChangeLog entry or whatnot.

I'll post it here, just after making them readable and comparable.

+    /* On a 32-bit system, rounding up vector size (in bytes) up
+       to mult-of-8 helps to maintain mult-of-8 alignment.  */
+    roundup_size = 8

This alignment is needed only if USE_LSB_TAG, right?  If so, the
roundup should occur only on such hosts.

It looks like you miss the core idea behind this code.

The rounding is not just to force alignment. For the block-allocated vectors,
this code rounds each possible vector size (in bytes) up to nearest
mult-of-roundup_size bytes, and then uses (size / roundup_size) as an index
into vector_free_lists. I believe this is the most natural way for both 32
and 64-bit systems with USE_LSB_TAG since it guarantees expected alignment
by design. On non-USE_LSB_TAG system, roundup_size is orthogonal to pointer
values (roundup_size can't be less than sizeof (Lisp_Object), of course).
For example, 32-bit system (non-wide-int, i.e. sizeof (Lisp_Object) == 4)
without USE_LSB_TAG is expected to work with roundup_size = 4, but I can't
test this and have no ideas why it's worth trying at all.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]