On Tuesday, 6 February 2024 22:02:11 PST Marc Mutz via Development wrote:
> As someone who argues that qHash("Hello"_L1) be restored to
> qHash(u"Hello"_s) after this relation was broken somewhere in Qt 5, how
> could I argue against it? :)It was commit ea8e48a6799cf742ea23f4a30dcfc38a4988fe56 in 5.3.0. commit ea8e48a6799cf742ea23f4a30dcfc38a4988fe56 Author: Thiago Macieira <[email protected]> Date: Thu Dec 19 23:32:04 2013 -0800 Update the qHash function for strings to use the CRC32 instruction According to my profiling of Qt Creator, qHash and the SHA-1 calculation are the hottest spots remaining in QtCore. The current qHash function is not really vectorizable. We could come up with a different algorithm that is more SIMD-friendly, but since we have the CRC32 instruction that can read 32- and 64-bit entities, we're set. This commit also updates the benchmark for QHash and benchmarks both the hashing function itself and the QHash class. The updated benchmarks for the CRC32 on my machine shows that the hashing function is *always* improved, but the hashing isn't always. In particular, the current algorithm is better for the "numbers" case, for which the data sample differs in very few bits. The new code is 33% slower for that particular case. On average, the improvement (including the "numbers" case) is: compared to qHash only QHash Qt 5.0 function 2.54x 1.06x Qt 4.x function 4.34x 1.34x Java function 2.71x 1.11x Now (current = siphash & murmurhash; nonzero_curent = aeshash; we don't have the CRC32 algorithm any more): RESULT : tst_QHash::hashing_qt4():"numbers": 126,800.35305 CPU cycles per iteration, 4.66 GHz 470,120.00894 instructions per iteration, 3.708 instr/cycle RESULT : tst_QHash::hashing_qt50():"numbers": 83,198.10215 CPU cycles per iteration, 4.64 GHz 365,099.00604 instructions per iteration, 4.388 instr/cycle RESULT : tst_QHash::hashing_current():"numbers": 151,220.07727 CPU cycles per iteration, 4.66 GHz 615,149.01052 instructions per iteration, 4.068 instr/cycle RESULT : tst_QHash::hashing_nonzero_current():"numbers": 65,224.59934 CPU cycles per iteration, 4.45 GHz 235,073.00508 instructions per iteration, 3.604 instr/cycle So even the pathological "numbers" case is now faster by about 27%. With "typical" data ("paths-small"): qt4: 23,848.939476 CPU cycles per iteration qt50: 11,681.268231 CPU cycles per iteration current: 10,623.703491 CPU cycles per iteration aeshash: 2,870.472204 CPU cycles per iteration The siphash/murmurhash implementation is slightly faster than the Qt 5.0 implementation and both are over twice as fast as the 4.x implementation. The aeshash is on average 3.7x faster than even those two. And with very long data ("longstrings-list"): qt4: 397,145.21743 CPU cycles per iteration qt50: 225,105.45316 CPU cycles per iteration siphash: 102,900.78968 CPU cycles per iteration aeshash: 10,249.00974 CPU cycles per iteration That's 10x faster on my laptop, which has 256-bit AES. With just 128-bit AES, my Skylake workstation is doing about 3.5x better than siphash for this case. See more numbers in https://codereview.qt-project.org/c/qt/qtbase/+/537009 -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering
smime.p7s
Description: S/MIME cryptographic signature
-- Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
