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.