[Development] Updating x86 SIMD support in Qt
Thiago Macieira
thiago.macieira at intel.com
Sun Jan 23 19:39:43 CET 2022
On Saturday, 22 January 2022 10:41:50 PST Lisandro Damián Nicanor Pérez Meyer
wrote:
> Keeping the distros able to use whatever baseline is indeed a first
> good step, but I'm also thinking about proprietary apps that might be
> using tQtC's build for their offerings. We used this very same machine
> with Zoom meetings for our kids' school meetings while they couldn't
> go to school due to COVID. It proved very useful.
That's an interesting and good point. It used to be possible to distinguish a
commercial build from an open source one back in Qt 3 and 4 days by using the
"strings" command and searching for the strings that were added by configure
during the initial build. I think that changed part-way through Qt 4 and by
4.8, which is the last release I was still at Nokia for, the binaries were
indistinguishable (evaluation binaries were different).
I expect that most of those tools are therefore simply using whatever binaries
they obtained from The Qt Company and didn't rebuild from source. I think this
is how we at Intel do for the installers for the oneAPI SDK on Linux and macOS
(the Windows installer got rewritten a few years ago).
Open Source tools probably just ship what they got from download.qt.io. Makes
things much simpler... which is also part of the reason why I want to raise
the minimum and do multi-arch.
So if my proposal had been in effect for those releases, it's quite likely the
tools wouldn't have run on your 13+-year-old computer.
But it isn't. We're talking about the next release, 6.4. There won't be any
tools built with it until the second half of this year, and commercial
customers may even want to wait for the LTS release after that.
> I don't know if the linker capability in using the right library
> version can be used in these specific cases, but if somehow it could
> be done it would be just wonderful.
It can be, it's a matter of our deciding what the minimum and other
optimisation options are.
On Windows, with MSVC, there's no question to be answered. It's only the
baseline. On Windows with either of the MinGW-capable compilers, we can choose
the minimum, but there's no option for runtime selection. In either case,
since Microsoft isn't interested in providing the tools to make code run fast
in their OS, I say we agree and keep on wasting CPU.
On Linux, we can have the multiple versions. I proposed a minimum of v2 and an
option of v3, but we can always choose v1+v2+v3. But I really want v2 and v3
for the critical libraries.
On macOS, the minimum today is already v2, but I am proposing raising it to v3
because we no longer support the OSes that supported v2 CPUs.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel DPG Cloud Engineering
More information about the Development
mailing list