[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