Re: vhash speed thread safeness

[ludo@gnu.org (Ludovic Courtès)]

Stefan Israelsson Tampe <stefan.itampe@gmail.com> skribis:

> On Tue, Oct 29, 2013 at 1:34 PM, Ludovic Courtès <ludo@gnu.org> wrote:
>
>> Hi, Stefan,
>>
>> Stefan Israelsson Tampe <stefan.itampe@gmail.com> 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.

OK.

[...]

>> > 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:

  http://www.gnu.org/software/mit-scheme/documentation/mit-scheme-ref/Weight_002dBalanced-Trees.html

Thoughts?

Thanks,
Ludo’.