Hennadii Stepanov

> Concept ACK. Looking at the [leveldb godbolt link](https://godbolt.org/z/45S0ID), this is nicely optimized everywhere except MSVC. However, the changes in MSVC generated assembly code look quite significant. > I'm ok...

> > However, the changes in MSVC generated assembly code look quite significant. > > Before stacking another performance deterioration change on top of the pile > > Isn't that...

What benchmarks might be appropiate for testing changes like these?

> Is there a venue for reporting this to MSVC? They recently [patted themselves on the back for detecting similar patterns](https://devblogs.microsoft.com/cppblog/a-tour-of-4-msvc-backend-improvements/). It's a shame MSVC can't detect something that (in...

> We can cherry-pick one commit from upstream leveldb, make the same change in crc32c, and then ultimately drop our build infra for testing endianness. The same goal, which is...

> However, my preference would be to completely avoid `signed char` and just use `int8_t` in the serialization code. That is, fix the test to use `int8_t`. I lean to...

> Happy to review a pull, if someone creates one. Please see https://github.com/bitcoin/bitcoin/pull/29907.

> Hmm, does our CI not run the fuzz corpus when building with MSVC? No, it does not. Even a fuzz binary is not built.

I've add a [benchmark](https://github.com/hebasto/bitcoin/commit/0f5abaf980122cce1bd0d405d17db3bfab273afa) for the `FeeRateCompare` function, which calls `Mul` twice. Here are results on Windows 11, `Release` configuration, which implies `/O2 /Oi` compile flags: - master branch @...

@sipa > Would you mind benchmarking with smaller realistic numbers (say fee and size both between 0 and 2^30)? I switched to `FastRandomContext::randbits(30)`. > If the top limb is equal,...