Simple RVV implementation of adler32. #55
Conversation
This implementation works in short 22-iteration batches, which avoids overflowing 16-bit counters so we get better parallelism in the inner loop.
Replace SiFive code for an alternative checksum implementation that works in short 22-iteration batches thus avoiding overflowing 16-bit counters. As a result, it has better parallelism in the inner loop, yielding a +20% faster checksum speed on a K230 board. The average *decompression* gain while using the zlib wrapper for the snappy data corpus was +2.15%, but with near +4% for HTML. Patch by Simon Hosie, from: cloudflare/zlib#55 Bug: 329282661 Change-Id: I72e2ce9bb9b3d8626dedb33cf026f1af9b9b4a33 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5433273 Reviewed-by: Hans Wennborg <hans@chromium.org> Commit-Queue: Adenilson Cavalcanti <cavalcantii@chromium.org> Cr-Commit-Position: refs/heads/main@{#1284684}
Replace SiFive code for an alternative checksum implementation that works in short 22-iteration batches thus avoiding overflowing 16-bit counters. As a result, it has better parallelism in the inner loop, yielding a +20% faster checksum speed on a K230 board. The average *decompression* gain while using the zlib wrapper for the snappy data corpus was +2.15%, but with near +4% for HTML. Patch by Simon Hosie, from: cloudflare/zlib#55 Bug: 329282661 Change-Id: I72e2ce9bb9b3d8626dedb33cf026f1af9b9b4a33 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5433273 Reviewed-by: Hans Wennborg <hans@chromium.org> Commit-Queue: Adenilson Cavalcanti <cavalcantii@chromium.org> Cr-Commit-Position: refs/heads/main@{#1284684} NOKEYCHECK=True GitOrigin-RevId: f68eb88e6ac1139355bad9d1f1eff784e9e82afb
|
Unfortunately we're not using RISC-V, so this is hard to review and test, and we can't commit to maintaining it. |
|
Yeah, that makes sense. The original reasoning for choosing the Cloudflare fork as the basis for RISC-V work was that it was the healthiest-looking version in GitHub and I didn't want to start another fork. But that was before I understood how active Google was with Android and Chrome on RISC-V, so that's probably the best place to work from. |
|
Will focus risc-v patches upstream in chromium and aosp (as per the "referenced by" links already added here) |
You were aware of zlib-ng? I think it's safe to say that zlib-ng is a more forward-looking, future-proof alternative with, as far as I can tell, perfect ABI compatibility if configured for that ( |
|
I wouldn’t mind getting such patches backported from the upstream zlib or zlib-ng, because then hopefully they would be maintaining these features, and it’s better for us to have fewer differences between zlib forks. |
This implementation works in short 22-iteration batches, which avoids overflowing 16-bit counters so we get better parallelism in the inner loop.