Re: [Development] What's our policy on changing the result of qHash(T, 0) between major releases?
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
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.54x1.06x
Qt 4.x function 4.34x1.34x
Java function2.71x1.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
Re: [Development] What's our policy on changing the result of qHash(T, 0) between major releases?
On 05.02.24 23:42, Thiago Macieira wrote:
> On Monday, 5 February 2024 01:36:39 PST Marc Mutz via Development wrote:
>> I've always understood it such that we as Qt must preserve the property
>> that the hash for equal elements is equal within _one_ run of _one_
>> process. This means you can use the hash in I/O in any way. That's why
>> we have qt_hash, which you _can_ (and do) use in I/O (but is private
>> API, AFAIK). I never thought that a hash seed of zero would change that,
>> but of course users may have come to depend on this (Hyrum's Law), so a
>> [ChangeLog] would be in order.
>
> In commit e3f05981cbeb0b7721f960ef88effa77be2af5ce, I added this comment to
> qHashBits:
> // mix in the length as a secondary seed. For seed == 0, seed2 must be
> // size, to match what we used to do prior to Qt 6.2.
>
> Which is why I am asking now, because making this change would go against that
> comment. But there was no discussion in the change about whether this was
> correct or not. It seems I just write it like that.
>
> However, that was qHashBits(). The change I'm talking about is
> qHash(QLatin1StringView), specifically so it won't call qHashBits().
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? :)
--
Marc Mutz
Principal Software Engineer
The Qt Company
Erich-Thilo-Str. 10 12489
Berlin, Germany
www.qt.io
Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht Charlottenburg,
HRB 144331 B
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] What's our policy on changing the result of qHash(T, 0) between major releases?
On 05.02.24 19:07, apoenitz wrote: > On Mon, Feb 05, 2024 at 09:36:39AM +, Marc Mutz via Development wrote: >> Hi, >> >> I've always understood it such that we as Qt must preserve the property >> that the hash for equal elements is equal within _one_ run of _one_ >> process. > > This would make debugging and testing of applications using QHash > less deterministic. > > There needs to ba some way to guarantee identical behavior of multiple runs > of the same binary. Setting the seed to 0 is currently such a way You're right, my comment was overly simplistic. The non-determinism should be in the seed, and nowhere else. So developers should be able to rely on hash functions yielding the same value if the same seed is given _and the same Qt version is used_. That doesn't mean that applications or developers can rely on seed = 0 yielding the same hash value across Qt releases (even patch ones). The end result is the same, though: we can - definitely change exported qHash() functions - definitely _not_ change inline qHash() functions - possibly _not_ change any other qHash() function (there shouldn't be any in this category, but historically, there were some). Hope that clears it up. Thanks, Marc -- Marc Mutz Principal Software Engineer The Qt Company Erich-Thilo-Str. 10 12489 Berlin, Germany www.qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Meeting minutes from Qt Release Team meeting 06.02.2024
Qt 6.6 status * Qt 6.6.2 release content was frozen but new blocker was found * Fixing ongoing, the target is to re-freeze the release content later this week. * The target is to release Qt 6.6.2 as soon as possible. Most probably this will happen at the beginning of next week. Qt 6.7 status: * Qt 6.7.0 Beta2 released and Qt 6.7.0 Beta3 preparations started. The target is to release Qt 6.7.0 Beta3 by the end of next week * API review is still ongoing, see https://bugreports.qt.io/browse/QTBUG-119952 * Updating 3rd party components for Qt 6.7.0 mostly done, see https://bugreports.qt.io/browse/QTBUG-121323 * Qt 6.7.0 Soft string freeze announced. Official String Freeze for Qt 6.7.0 will be in effect Tue 13th February 2024 Next meeting Tue 13th February 2024 16:00 CET br, Jani Heikkinen Release Manager irc log below: [17:00:03] <+jaheikki3> ablasche: akseli: carewolf: frkleint: mapaaso: The-Compiler: thiago: vohi: ping [17:02:11] pong [17:02:26] jaheikki3: pong [17:02:28] <+jaheikki3> Let's start from Qt 6.6 status [17:02:47] <+jaheikki3> t 6.6.2 release content was frozen but new blocker was found [17:03:13] <+jaheikki3> Fixing ongoing, the target is to re-freeze the release content later this week [17:03:22] jaheikki3: pong [17:03:50] <+jaheikki3> And the target is to release Qt 6.6.2 as soon as possible [17:04:13] <+jaheikki3> But because packages aren't in place the release won't happen during this week [17:04:31] <+jaheikki3> Hoping the release can happen at the beginning of next week [17:04:50] <+jaheikki3> That's all about Qt 6.6 status at this time. Any comments or questions? [17:06:08] <+jaheikki3> Ok, next Qt 6.7 status [17:06:20] <+jaheikki3> Qt 6.7.0 Beta2 released last week [17:06:42] <+jaheikki3> And Qt 6.7.0 Beta3 preparations started. The target is to release Qt 6.7.0 Beta3 by the end of next week [17:06:59] <+jaheikki3> API review is still ongoing, see https://bugreports.qt.io/browse/QTBUG-119952 [17:07:40] <+jaheikki3> Some reviews still open but it seems reviews are progressing [17:07:59] <+jaheikki3> Updating 3rd party components for Qt 6.7.0 mostly done, see https://bugreports.qt.io/browse/QTBUG-121323 [17:08:34] <+jaheikki3> Qt 6.7.0 Soft string freeze announced, official String Freeze will be in effect Tue 13th February 2024 [17:09:04] <+jaheikki3> That's actually all about Qt 6.7 status at this time. Any comments or questions? [17:09:32] we had a question whether the qHash(quint128) code could be added to it [17:09:44] it was found byy API review in 6.6 but the implementation wasn't done until a few days ago [17:10:02] hmm... volker isn't here to opine [17:11:04] <+jaheikki3> Yeah, vohi is in workshop so let's discuss about that in ml [17:11:56] ok [17:12:48] <+jaheikki3> ok, it was all at this time so let's end this meeting now & have new one tue 13th February at this same time [17:12:57] <+jaheikki3> thanks for your participation, bye! [17:13:11] bye [17:13:46] bye [17:14:46] bye -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] HEADS UP : Qt 6.7 soft string freeze
Hi all, First beta releases from Qt 6.7 are out and it is time to start keeping translatable strings as it is. The official string freeze for Qt 6.7 will be in effect Tue 13th of February 2024. br, Jani Heikkinen Release Manager -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Nominating Hatem ElKhrarashy for approval status
+1 On 2/6/24 10:18, Janne Koskinen via Development wrote: I would like to nominate Hatem Elkharashy for approver rights in the Qt project. Hatem has been working on Qt Graphics for 2,5 years contributing to QtQuick3D, QtCharts, QtDeclarative, QtBase and most recently on QtSvg. Changes where he is the author: https://codereview.qt-project.org/q/owner:hatem.elkharashy%2540qt.io Changes where he is reviewer: https://codereview.qt-project.org/q/reviewer:hatem.elkharashy%2540qt.io -Janne Koskinen -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Nominating Hatem ElKhrarashy for approval status
+1 From: Janne Koskinen Sent: Tuesday, February 6, 2024 11:18 To: 'Qt development mailing list' Cc: Hatem ElKharashy Subject: [Development] Nominating Hatem ElKhrarashy for approval status I would like to nominate Hatem Elkharashy for approver rights in the Qt project. Hatem has been working on Qt Graphics for 2,5 years contributing to QtQuick3D, QtCharts, QtDeclarative, QtBase and most recently on QtSvg. Changes where he is the author: https://codereview.qt-project.org/q/owner:hatem.elkharashy%2540qt.io Changes where he is reviewer: https://codereview.qt-project.org/q/reviewer:hatem.elkharashy%2540qt.io -Janne Koskinen -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Nominating Hatem ElKhrarashy for approval status
+1 🙂 Eskil Abrahamsen Blomfeldt Senior Manager, Graphics The Qt Company Sandakerveien 116 0484 Oslo, Norway eskil.abrahamsen-blomfe...@qt.io http://qt.io From: Development on behalf of Janne Koskinen via Development Sent: Tuesday, February 6, 2024 10:18 AM To: 'Qt development mailing list' Cc: Hatem ElKharashy Subject: [Development] Nominating Hatem ElKhrarashy for approval status I would like to nominate Hatem Elkharashy for approver rights in the Qt project. Hatem has been working on Qt Graphics for 2,5 years contributing to QtQuick3D, QtCharts, QtDeclarative, QtBase and most recently on QtSvg. Changes where he is the author: https://codereview.qt-project.org/q/owner:hatem.elkharashy%2540qt.io Changes where he is reviewer: https://codereview.qt-project.org/q/reviewer:hatem.elkharashy%2540qt.io -Janne Koskinen -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Nominating Hatem ElKhrarashy for approval status
I would like to nominate Hatem Elkharashy for approver rights in the Qt project. Hatem has been working on Qt Graphics for 2,5 years contributing to QtQuick3D, QtCharts, QtDeclarative, QtBase and most recently on QtSvg. Changes where he is the author: https://codereview.qt-project.org/q/owner:hatem.elkharashy%2540qt.io Changes where he is reviewer: https://codereview.qt-project.org/q/reviewer:hatem.elkharashy%2540qt.io -Janne Koskinen -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
