Remco Bloemen

Yeah, that should be `x

This shaves of 1 gas and introduces awesome de Bruijn sequences. 👍 If you want bigger gas savings, you can bring `lnWad` down from 614 gas to 585 gas by...

This is where the original value came from: https://twitter.com/recmo/status/1744470975872127005 The rational approximation may go from 0 to 1 earlier or later than this exact value. A) If it is earlier,...

Happy to contribute here if I can get some assurances that such a PR is welcome.

This is really cool, I expect it to be a big improvement over `Vec`. Contiguous memory FTW! 🚀

I have a cache oblivious transpose here: https://github.com/recmo/OpenZKP/blob/master/algebra/primefield/src/fft/transpose.rs Transposition will become the bottleneck in FFT once you go beyond CPU cache sizes and have solved all the other bottlenecks. In...

3x faster than keccak is a bit suspecious, something must be off with the keccak impl.

I changed `KeccakHasher` to avoid allocations and use the `tiny-keccak` library directly. The `keccak-hash` crate is a thin wrapper around `tiny-keccak` with a less flexible interface that also pulls in...

Blake3 trees. Looks about 10% faster. I was expecting more so will dig into it. ``` Benchmarking merkle-tree/8192: Collecting 10 samples in estimate merkle-tree/8192 time: [4.0060 ms 4.0256 ms 4.0615...

So the keccak/blake3 gap looks mostly due to keccak's large state size, which amortizes for larger inputs. For >= 128 input elements the blake3 advantage is a more reasonable ~20%....