komihash 5.27

[avaneev]

A minor update - changed prefetch locality from 2 to 3, seems to be favorable to SMHasher. Also changed 64x64 mul to __uint128_t r = u; r *= v; style. If that does not help to boost Ryzen 3 speeds, nothing else will. Anyway, things may change when you upgrade your severely outdated Ryzen.

[rurban]

I also benchmark with much better processors, like Ryzen 5, Epyc or i7. But the standard is conservative

[avaneev]

Yes, I saw other benchmarks. On EPYC komihash performs a lot better. I think the standard should target processors that are on a wide server, desktop, and laptop market now - Zen3, Zen4, RaptorLake, RocketLake. You can't really buy Zen+ anymore.

[avaneev]

If you are not using -march=znver1 with GCC on Zen+, it may be worth using it - this instruction set enables the mulx x86-64 instruction which may provide a different performance, because its operands are not limited like in x86 mul instruction - hence, less register shuffling happens.

[avaneev]

Or add -mbmi2 compiler option. It's a fairly portable option - supported by most CPUs in use today.

[rurban]

I'm using -march=native on all x64 platforms, which includes all your flags

[avaneev]

That's reasonable. Still, very weird performance results. In other benchmarks it's 0.18 cycles/byte on Zen1, with both GCC and Clang.

On Zen5 with the latest SMHasher and GCC 13 I get (processor frequency is misreported it seems, in Windows 11 task manager it's 5.5 GHz):

--- Testing komihash "komihash 5.25" GOOD

[[[ Speed Tests ]]]

Bulk speed test - 262144-byte keys
Alignment 7 - 9.835 bytes/cycle - 41062.25 MiB/sec @ 4378 MHz
Alignment 6 - 9.832 bytes/cycle - 41051.39 MiB/sec @ 4378 MHz
Alignment 5 - 9.831 bytes/cycle - 41047.89 MiB/sec @ 4378 MHz
Alignment 4 - 9.833 bytes/cycle - 41052.59 MiB/sec @ 4378 MHz
Alignment 3 - 9.832 bytes/cycle - 41050.59 MiB/sec @ 4378 MHz
Alignment 2 - 9.831 bytes/cycle - 41045.09 MiB/sec @ 4378 MHz
Alignment 1 - 9.831 bytes/cycle - 41044.53 MiB/sec @ 4378 MHz
Alignment 0 - 9.854 bytes/cycle - 41141.94 MiB/sec @ 4378 MHz
Average - 9.835 bytes/cycle - 41062.03 MiB/sec @ 4378 MHz

Wyhash:
--- Testing wyhash "wyhash v4.2 (64-bit)" GOOD

[[[ Speed Tests ]]]

Bulk speed test - 262144-byte keys
Alignment 7 - 9.719 bytes/cycle - 40521.73 MiB/sec @ 4372 MHz
Alignment 6 - 9.718 bytes/cycle - 40517.63 MiB/sec @ 4372 MHz
Alignment 5 - 9.716 bytes/cycle - 40510.29 MiB/sec @ 4372 MHz
Alignment 4 - 9.720 bytes/cycle - 40526.08 MiB/sec @ 4372 MHz
Alignment 3 - 9.715 bytes/cycle - 40505.79 MiB/sec @ 4372 MHz
Alignment 2 - 9.716 bytes/cycle - 40512.32 MiB/sec @ 4372 MHz
Alignment 1 - 9.716 bytes/cycle - 40512.05 MiB/sec @ 4372 MHz
Alignment 0 - 9.737 bytes/cycle - 40596.67 MiB/sec @ 4372 MHz
Average - 9.720 bytes/cycle - 40525.32 MiB/sec @ 4372 MHz

[avaneev]

rapidhash bulk is a tiny bit faster than komihash on Zen5. But on hashmaps, rapidhash is a regression relative to wyhash. Latest komihash is as fast as rapidhash for hash-maps on Zen5.

[avaneev]

I would also suggest to switch to Clang and eliminate Unix- and Posix-specific APIs, if you want to provide widest portability. GCC is Linux-loving compiler, its portability is a myth. I would not ship production code compiled with GCC on Windows - GCC forks like MinGW are problematic, various bugs here and there in compiler and RTL. For example, I had to adjust SMHasher for MinGW locally - pclmul code does not compile.

[avaneev]

I've finally decided to get Zen+ CPU for testing - I've got mini-PC with Ryzen 3550H processor at 2.1 GHz (3.3 GHz boost). When compiled with GCC 13 with corresponding arch, Rapidhash shows 22.8 GB/s while Komihash 5.27 shows 16.8 GB/s. This is way higher performance for Komihash than what you get in your benchmarks. So, my suspicions were valid - your performance testing is flawed.