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 <thiago.macie...@intel.com>
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 Development@qt-project.org https://lists.qt-project.org/listinfo/development
