[Development] Renaming quint128
Thiago Macieira
thiago.macieira at intel.com
Fri Nov 18 18:19:27 CET 2022
On Friday, 18 November 2022 04:16:48 PST Shawn Rutledge via Development wrote:
> On 2022 Nov 18, at 03:13, Thiago Macieira
> <thiago.macieira at intel.com<mailto:thiago.macieira at intel.com>> wrote:
> > I was working on extended integers and added qint128 and quint128 to
> > qglobal.h
> Interesting. How far can we go with doubling bits? quint512 in case you
> have AVX-512 registers? (I must get a laptop with that feature, next time;
> since even Zen 3 doesn’t have it, I still don’t have any machine that
> does)
That's not the same thing. The 128-bit integers are stored in general-purpose
registers and exist as a by-product of the compilers having code to work with
64-bit integers on 32-bit CPU. All the current architectures that went from 32
to 64-bit simply duplicated their "double word" instructions extending the
support to 128-bit, so the compilers did the same for their runtime support.
On x86, that's also the same set of instructions that allowed 32-bit
operations on the 16-bit processors.
I don't expect this to double again any time soon.
The AVX and AVX-512 registers don't operate as a single 128-, 256- or 512-bit
integer register. Instead, they operate as a vector of 8-, 16-, 32-, or 64-bit
entities ("lanes") and perform the same operation in parallel.
> Maybe CBOR bignums would have a use for it? Various kinds of hashes? I’d
> really like it if cryptographic hashes often ended up being numeric again.
>
> QUuid should have a use for it.
Yep, turns out that this was the easiest way to deal with the QBluetoothUuid
problem. I wrote this unit test yesterday:
quint128 u = Q_UINT64_C(0xfc69b59ecc344436);
u <<= 64;
u |= Q_UINT64_C(0xa43cee95d128b8c5);
QUuid uuid(u);
QCOMPARE(uuid, uuidA);
QCOMPARE(quint64(uuid.toUInt128() >> 64), quint64(u >> 64));
QCOMPARE(quint64(uuid.toUInt128()), quint64(u));
I split the compares because I haven't added a QTest::toString of 128-bit
because I didn't extend the number-to-string support to QByteArray & QLocale.
I only added to QTextStream. See
https://codereview.qt-project.org/c/qt/qtbase/+/444222/1/src/corelib/
serialization/qtextstream.cpp#2256
> What else can we interoperate with? gmplib.org<http://gmplib.org> perhaps;
> maybe some C++ standard could be in the works?
GMP would be what I'd use to support CBOR bignums. But I don't think we'll
extend our support there, directly, in QtCore.
> What about having varints in Qt some day? (Like the way protobuf stores
> ints) I wonder why CBOR doesn’t have them.
CBOR has "regular integers" that can be any value between -2^64-1 to 2^64.
It's meant to be similar to JSON where you only have "number", not to enforce
a serialisation format. It chose to use a single type for integral numbers so
that all would benefit from being transmitted in fewer bytes in case of small
numbers, instead of having fixed size to accommodate the full range.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud Engineering
More information about the Development
mailing list