git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] last-modified: implement faster algorithm

From
Taylor Blau <me@ttaylorr.com>
Date
Oct 23, 2025, 23:59 UTC
Message-ID
<aPrBYGa6HWUtTI4V@nand.local>
In-Reply-To
<87cy6gtym2.fsf@iotcl.com>
On Tue, Oct 21, 2025 at 11:04:05AM +0200, Toon Claes wrote:
Show 28 quoted lines
> > Taylor Blau <me@ttaylorr.com> writes:
>
> >> Nice, I am glad to see that we are using a bitmap here rather than the
> >> hacky 'char *' that we had originally written. I seem to remember that
> >> there was a tiny slow-down when using bitmaps, but can't find the
> >> discussion anymore. (It wasn't in the internal PR that I originally
> >> opened, and I no longer can read messages that far back in history.)
> >>
> >> It might be worth benchmarking here to see if using a 'char *' is
> >> faster. Of course, that's 8x worse in terms of memory usage, but not a
> >> huge deal given both the magnitude and typical number of directory
> >> elements (you'd need 1024^2 entries in a single tree to occupy even a
> >> single MiB of heap).
>
> Using ewah bitmaps is slightly faster, although the difference is almost
> neglible.
>
>     Benchmark 1: bitmap-ewah
>       Time (mean ± σ):     793.1 ms ±   6.2 ms    [User: 755.1 ms, System: 35.2 ms]
>       Range (min … max):   784.7 ms … 804.8 ms    10 runs
>
>     Benchmark 2: bitmap-chars
>       Time (mean ± σ):     808.9 ms ±  11.2 ms    [User: 770.8 ms, System: 35.4 ms]
>       Range (min … max):   800.2 ms … 830.5 ms    10 runs
>
>     Summary
>       bitmap-ewah ran
>         1.02 ± 0.02 times faster than bitmap-chars

OK, makes sense, though just to clarify, "bitmap-ewah" is just a bog-standard "struct bitmap", right? That happens to come from the EWAH implementation, but the bitmap itself is not being EWAH compressed, right?

Show 28 quoted lines
> And ewah bitmap being more memory efficient, it makes more sense to keep
> using those.
>
> >> Likewise, I wonder if we should have elemtype here be just 'struct
> >> bitmap'. Unfortunately I don't think the EWAH code has a function like:
> >>
> >>     void bitmap_init(struct bitmap *);
> >>
> >> and only has ones that allocate for us. So we may consider adding one,
> >> or creating a dummy bitmap and copying its contents, or otherwise.
>
> I've done some testing, and to do so I've made bitmap_grow() public.
>
>     Benchmark 1: bitmap-as-pointers
>       Time (mean ± σ):     783.7 ms ±   8.9 ms    [User: 744.1 ms, System: 37.5 ms]
>       Range (min … max):   774.4 ms … 803.4 ms    10 runs
>
>     Benchmark 2: bitmap-as-values
>       Time (mean ± σ):     856.7 ms ±  10.5 ms    [User: 816.0 ms, System: 38.1 ms]
>       Range (min … max):   845.7 ms … 872.5 ms    10 runs
>
>     Summary
>       bitmap-as-pointers ran
>         1.09 ± 0.02 times faster than bitmap-as-values
>
> It seems using ewah bitmaps as pointers is faster than using bitmaps as
> values. I must admit I'm surprised as well, but in case you want to
> double check, here's the patch:

I think this makes sense; the pointers are half as wide as a struct bitmap. Even though we're going through another layer of indirection, I think that the smaller slab footprint results in better cache locality, and ultimately faster code. Thanks for testing it out.

Thanks, Taylor

Previous: Toon ClaesNext: Toon Claes
Message 12 of 39 in “last-modified: implement faster algorithm”
  1. last-modified: implement faster algorithmToon Claes, Oct 16, 2025
  2. Justin ToblerOct 16, 2025
  3. Toon ClaesOct 17, 2025
  4. D. Ben KnobleOct 16, 2025
  5. Toon ClaesOct 17, 2025
  6. Taylor BlauOct 16, 2025
  7. Jeff KingOct 17, 2025
  8. Taylor BlauOct 17, 2025
  9. Jeff KingOct 21, 2025
  10. Toon ClaesOct 17, 2025
  11. Toon ClaesOct 21, 2025
  12. Taylor BlauOct 23, 2025
  13. Toon ClaesOct 21, 2025
  14. Taylor BlauOct 23, 2025
  15. Toon ClaesOct 27, 2025
  16. Jeff KingOct 17, 2025
  17. Toon ClaesOct 17, 2025
  18. last-modified: implement faster algorithmToon Claes, Oct 21, 2025
  19. Junio C HamanoOct 21, 2025
  20. Taylor BlauOct 22, 2025
  21. Taylor BlauOct 22, 2025
  22. Junio C HamanoOct 22, 2025
  23. Taylor BlauOct 24, 2025
  24. Junio C HamanoOct 24, 2025
  25. Taylor BlauOct 27, 2025
  26. Toon ClaesOct 29, 2025
  27. Toon ClaesOct 23, 2025
  28. last-modified: implement faster algorithmToon Claes, Oct 23, 2025
  29. Taylor BlauOct 24, 2025
  30. Toon ClaesOct 27, 2025
  31. last-modified: implement faster algorithmToon Claes, Nov 3, 2025
  32. Junio C HamanoNov 3, 2025
  33. Toon ClaesNov 4, 2025
  34. t8020-last-modified.sh failure on s390x (Re: [PATCH v4] last-modified: implement faster algorithm)Anders Kaseorg, Nov 19, 2025
  35. Kristoffer HaugsbakkNov 19, 2025
  36. Anders KaseorgNov 19, 2025
  37. Jeff KingNov 20, 2025
  38. Toon ClaesNov 28, 2025
  39. Kristoffer HaugsbakkNov 28, 2025

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.