[Top][All Lists]

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

Re: vhash speed thread safeness

From: Ludovic Courtès
Subject: Re: vhash speed thread safeness
Date: Tue, 29 Oct 2013 18:54:56 +0100
User-agent: Gnus/5.130007 (Ma Gnus v0.7) Emacs/24.3 (gnu/linux)

Stefan Israelsson Tampe <address@hidden> skribis:

> On Tue, Oct 29, 2013 at 1:34 PM, Ludovic Courtès <address@hidden> wrote:
>> Hi, Stefan,
>> Stefan Israelsson Tampe <address@hidden> skribis:
>> > I did some tests witha C-based vhash implementation, it's possible to
>> > increse the speed by 30x compared to current vlist imlpementation in
>> > guile. It would be possible to get this speed today if one implemented
>> > vhash-assoc as a VM op. Anyway using the source as a standard lib will
>> > get you about 10x speed increase.
>> As we discussed, I don’t really like the idea of implementing that much
>> in C.
> My neither, but it is good to see that in cache friendly cases we can
> improve the situation 30x. Gives us a goal to strive for. Also the main
> intention is to use vashses for guile-log. For this we can note.



>> > Another pressing need is that vhashes are not thread safe,
>> Section 2.8 of Bagwell’s paper proposes a simple solution.  All that is
>> missing AFAICS is an atomic test-and-set VM op to implement it (which
>> may also be useful in other places.)
>> What do you think of this approach?
> For vlists it's probably a good idea, I don't know if it's enough for
> vhashes though.

Oooh, right, sorry for overlooking that.

> Maybe you need a mutex. But lock overhead will be significant

Surely, especially if it’s a fat mutex.

Hmm hmm.  Of course that could be an argument for doing some C
(primitives, not VM ops), but looking at ‘%vhash-assoc’, that would
clearly mean reimplementing pretty much all of the vlist + vhash in C,
which sucks.

I wonder if there’s some other data structure with similar properties
that doesn’t have the thread-safety issue.  Maybe Ian has an idea?

The weight-balanced trees in MIT/GNU Scheme look interesting:



reply via email to

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