[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?
Sure.
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.
Dmitry
- Re: Proposal: block-based vector allocator,
Dmitry Antipov <=
- Re: Proposal: block-based vector allocator, Paul Eggert, 2012/06/01
- Re: Proposal: block-based vector allocator, Dmitry Antipov, 2012/06/01
- Re: Proposal: block-based vector allocator, Stefan Monnier, 2012/06/01
- Re: Proposal: block-based vector allocator, Paul Eggert, 2012/06/01
- Re: Proposal: block-based vector allocator, Eli Zaretskii, 2012/06/02
- Re: Proposal: block-based vector allocator, Paul Eggert, 2012/06/03
- Re: Proposal: block-based vector allocator, Eli Zaretskii, 2012/06/03