On Sunday, 20 November 2022 18:38:08 PDT Thiago Macieira wrote:
> ("QString: replace #if with if constexpr...") and ending at
> https://codereview.qt-project.org/c/qt/qtbase/+/386952 ("
> QString::toLatin1: do the same as..."). The first six commits are merely
> clean- ups and reorganisation.
>
> I'll defer the AVX2 and AVX512VL improvements for 6.6.Well, it didn't happen because I haven't had the time to run the benchmarks and don't have a line of sight to when I'll have time for this. Therefore, the changes are still in limbo. Meanwhile, Intel announced today (yesterday GMT) the AVX10[1] and APX[2] instruction set extensions. Our objective is to get that baseline established as yet another sub-arch and get Linux distributors not only to adopt it, but to rebuild a considerable chunk of their software using it. [1] https://cdrdv2.intel.com/v1/dl/getContent/784267 [2] https://cdrdv2.intel.com/v1/dl/getContent/784266 AVX10 is basically all of AVX512 in 256-bit form. Similarity with the work starting in https://codereview.qt-project.org/c/qt/qtbase/+/387415 (see also https://lists.qt-project.org/pipermail/development/2022-January/042083.html for the discussion in January 2022) is NOT a coincidence. I'd known this was coming and as planning on simply updating the CPUID detection to enable it, but anyway the work is done and I've been running my own code for 2 years now, but it's still unmerged. Therefore, help benchmarking is appreciated. Obviously, we won't be able to benchmark the AVX10.2 implementations for Atoms and laptop CPUs until those are in the market. I've also evolved on my recommendations for the rest of this discussion since I've last posted: > But the short story is: > * On all x86-64 builds, the new default will be the v2 sub-architecture, > which is this month 14 years old, and is the minimum on all x86-64 Android > and Macs anyway, and is the new minimum on Red Hat 9. This can be > overridden up or down by the user with the new QT_BUILD_SUBARCH variable. I will make one last push to the WIP changes in gerrit, for the record, then abandon. This functionality needs to be in CMake itself, not inside the Qt CMake files. I plan on facilitating this discussion with their devs. Should CMake not make such changes, Linux distributions will probably just build the software twice and install one on top of the other, like Clear Linux was doing 7 years ago already. I recommend the Qt Company apply either technique on its own binary builds, but I won't make the actual changes. That's SEP. > * On Macs, the new default will be the v3 sub-architecture (Apple calls it > "x86-64h") and can similarly be overridden with either that variable or the > CMAKE_OSX_ARCHITECTURES variable. It should be possible to extend my code to > do both x86-64 and x86-64h multiarch on macOS, but I don't plan on spending > time on this, because ALL currently supported Macs can run AVX2. In line with the "SEP to make it happen" above for Linux and the reduced importance of x86 for the Mac world, I have already abandoned all the relevant changes. Qt Company and Qt users can build either x86_64h or x86_64+x86_64h fat binaries for their software if they want. I recommend that and the recommendation hasn't changed. But I won't be implementing the changes like the patches-to-be-abandoned were doing -- just build twice and lipo everything together. Maybe CMake can be updated to do it for us, but driving that change is SEP. Patches abandoned: https://codereview.qt-project.org/c/qt/qtbase/+/444968 https://codereview.qt-project.org/c/qt/qtbase/+/444969 https://codereview.qt-project.org/c/qt/qtbase/+/444538 -- 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
