[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: HAMT for gl_set and gl_map
From: |
Bruno Haible |
Subject: |
Re: HAMT for gl_set and gl_map |
Date: |
Sun, 11 Oct 2020 16:01:02 +0200 |
User-agent: |
KMail/5.1.3 (Linux/4.4.0-189-generic; KDE/5.18.0; x86_64; ; ) |
Hi Marc,
> > How would a HAMT implementation look like that does not support persistence,
> > but is instead optimized for destructive updates? Probably the reference
> > counters would go away. Anything else?
>
> The reference counter would go away as would all tests for "shared" in the
> code.
>
> Without a reference counter, an element can be any "void *" (instead
> of a pointer to a struct starting with Hamt_entry), which is a
> substantial change.
Thanks for explaining.
> We can add a number of #if's to the code so that it either compiles to
> an implementation of persistent or of transient hamts, but I wouldn't
> rather do it right now because it would make the code harder to read.
> But when the hamt code has become stable (and has been put to use and,
> therefore, to real-world testing), this sounds like a feasible option.
I agree that stabilizing the current code should come first.
Then, whether the adaptations will be doable with a small set of #ifs
or whether it will be best to copy the code, will remain to be seen.
I mean, there are different red-black tree implementations in Gnulib
and in the Linux kernel, and it does not cause maintenance problems
because algorithmic code only very rarely needs updates.
Bruno
- Re: HAMT iterator, (continued)
- Re: HAMT iterators, Bruno Haible, 2020/10/11
- Re: HAMT iterators, Marc Nieper-Wißkirchen, 2020/10/11
- Re: HAMT iterators, Bruno Haible, 2020/10/11
- Re: out-of-memory handling, Bruno Haible, 2020/10/11
- Re: out-of-memory handling, Marc Nieper-Wißkirchen, 2020/10/11
- Re: out-of-memory handling, Bruno Haible, 2020/10/11
- Re: out-of-memory handling, Marc Nieper-Wißkirchen, 2020/10/11
- Re: HAMT for gl_set and gl_map,
Bruno Haible <=
- Re: [New module] Persistent Hash Array Mapped Tries (HAMTs), Marc Nieper-Wißkirchen, 2020/10/11
- Re: Draft #3 (with iterators), Marc Nieper-Wißkirchen, 2020/10/11
- Re: Draft #3 (with iterators), Bruno Haible, 2020/10/11
- Re: Non-opaque hamt type?, Marc Nieper-Wißkirchen, 2020/10/12
- Re: Non-opaque hamt type?, Bruno Haible, 2020/10/18
- Re: Non-opaque hamt type?, Marc Nieper-Wißkirchen, 2020/10/18
- Re: Non-opaque hamt type?, Bruno Haible, 2020/10/18
- Re: Non-opaque hamt type?, Marc Nieper-Wißkirchen, 2020/10/18
- Re: terminology, Bruno Haible, 2020/10/11
- Re: terminology, Marc Nieper-Wißkirchen, 2020/10/11