Re: Formal review request for Hash2

From: Peter Dimov (pdimov_at_[hidden])
Date: 2024-12-04 18:58:37

Ivan Matek wrote:
> But original reason why I wanted to do this with span is that I wondered about
> performance.
> I wanted to see what happens when we do same thing(hashing of all
> contiguous struct members) in 3 ways.
> 
> 1.	just call hash_append for each member
> 2.	exploit that before padding we are contiguous and trivial so pass that
> region in one call to hash_append_range
> 3.	Use BOOST_DESCRIBE_STRUCT automagic
> 
> Long story short is that for some hashes it makes no difference, but on my
> machine for sha2_256 and ripemd_128 there exist small but reliable
> performance differences.
> Ranking is: 2. is fastest, 3. slowest, 1. in the middle.
> I am not surprised that 2. is a bit faster than 1. since we make just 1 call, but it
> is a bit weird that 3. is slower than 1., I would guess that described class
> expand into same code as case 1.
> 
> Could be just compiler randomly deciding to inline/unroll something or not,
> but I wonder if you are aware of this differences. Maybe my assumption that
> describe does not do anything differently than manually written calls for each
> member is wrong?
> Code is here <https://godbolt.org/z/WzPG54aTd> , but it does not compile
> since IDK how to get hash2 onto godbolt, and anyway godbolt is too noisy to
> test little perf differences. I have tested this with libc++ and clang 19.

Yeah, it's annoying that it can't "just work" somehow on CE. That's why I
submit libraries to Boost, so that they show up there.

One can manually copy and paste the necessary headers:

https://godbolt.org/z/5Maf9Mx9h

Using a "hash archetype" (a skeleton algorithm that doesn't have any definitions)
it seems that MyStruct1 and MyStruct3 generate the exact same code, so it must
be inlining shenanigans.

mp_for_each, which the described class code uses, probably adds a few more
function calls that push things over some Clang limit.

As a general rule, Clang is more conservative with inlining than GCC is, especially
at -O3.