From: David Kastrup <dak@gnu.org>
To: guile-devel@gnu.org
Subject: Re: Growable arrays?
Date: Thu, 14 Jun 2012 19:49:10 +0200 [thread overview]
Message-ID: <87395xvl61.fsf@fencepost.gnu.org> (raw)
In-Reply-To: CAN3veRfU9MkRYn6QRu4taSbksySUS1ZGBzJBihLfpft_y6TVUw@mail.gmail.com
Daniel Hartwig <mandyke@gmail.com> writes:
> On 15 June 2012 01:15, David Kastrup <dak@gnu.org> wrote:
>> Daniel Hartwig <mandyke@gmail.com> writes:
>>> What is this half-in-place algorithm that makes this efficient? If
>>> the table is to remain balanced, all items should be rehashed and
>>> reallocated to a new bucket and there is no correlation between an
>>> items old and new buckets (hash).
>>
>> Huh? Hashing computes a hash value, and the bucket is determined by
>> hash % vectorsize. Double the vector size, and the new bucket locations
>> are at bucket and bucket+vectorsize, so you need to coalesce the bucket
>> at bucket into the buckets at bucket and bucket+vectorsize.
>>
>> Why would there be no correlation between old and new buckets when they
>> are calculated based on the same hash code?
> …
>
> I see. So starting from the old tail there is little contention for
> the new buckets. This seems obvious now in hindsight :-)
>
> Regarding the data type for your application, this is something which
> needs to be accessible from the c side also?
No. And we have significant amount of C code of our own, so adding
stuff here is not a problem. And we are talking about rather
performance-critical stuff.
For one thing, it feels ridiculous having to implement a rather basic
data type oneself. For another, growing a memory area can sometimes be
done in-place when one talks nicely to the garbage management (allocate
from the free space following the resizable vector preferably backwards,
so that resizing may still be opportunistically possible. Or allocate
the vector itself backwards and try growing it backwards in memory).
There are various strategies that might be more efficient than the
"naive relocator" but that can't be done without actually meddling with
Guile internals.
--
David Kastrup
prev parent reply other threads:[~2012-06-14 17:49 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-09 12:32 Growable arrays? David Kastrup
2012-06-09 14:43 ` Krister Svanlund
2012-06-09 17:35 ` David Kastrup
2012-06-11 4:23 ` Daniel Hartwig
2012-06-11 4:37 ` David Kastrup
2012-06-11 5:00 ` Daniel Hartwig
2012-06-11 7:25 ` David Kastrup
2012-06-11 9:01 ` Daniel Hartwig
2012-06-11 9:13 ` Daniel Hartwig
2012-06-11 10:38 ` David Kastrup
2012-06-11 11:57 ` Daniel Hartwig
2012-06-11 12:13 ` Noah Lavine
2012-06-11 12:28 ` David Kastrup
2012-06-11 23:50 ` Mark H Weaver
2012-06-12 9:34 ` David Kastrup
2012-06-12 20:34 ` Mark H Weaver
2012-06-12 20:47 ` David Kastrup
2012-06-12 21:03 ` Mark H Weaver
2012-06-12 21:18 ` David Kastrup
2012-06-11 8:14 ` Thien-Thi Nguyen
2012-06-11 9:08 ` Andy Wingo
2012-06-11 9:55 ` David Kastrup
2012-06-11 11:25 ` Andy Wingo
2012-06-11 12:00 ` David Kastrup
2012-06-11 12:12 ` David Kastrup
2012-06-11 12:20 ` David Kastrup
2012-06-11 13:04 ` Daniel Hartwig
2012-06-11 14:19 ` David Kastrup
2012-06-11 15:24 ` Stefan Israelsson Tampe
2012-06-11 15:27 ` Andy Wingo
2012-06-11 16:03 ` David Kastrup
2012-06-11 12:20 ` Daniel Hartwig
2012-06-11 12:36 ` David Kastrup
2012-06-11 12:02 ` Ludovic Courtès
2012-06-12 13:36 ` Hans Aberg
2012-06-14 14:33 ` Mark H Weaver
2012-06-14 14:47 ` David Kastrup
2012-06-14 15:23 ` Daniel Hartwig
2012-06-14 15:34 ` David Kastrup
2012-06-14 16:56 ` Daniel Hartwig
2012-06-14 17:15 ` David Kastrup
2012-06-14 17:23 ` Daniel Hartwig
2012-06-14 17:49 ` David Kastrup [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87395xvl61.fsf@fencepost.gnu.org \
--to=dak@gnu.org \
--cc=guile-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).