Re: [Development] Implicit VFMADD support (Was: Updating x86 SIMD support in Qt)

2022-01-24 Thread Konstantin Shegunov 
On Mon, Jan 24, 2022 at 8:50 PM Thiago Macieira 
wrote:

> If you're talking about code in Qt, simply use std::fma and it'll do the
> right
> thing. It becomes my problem to optimise it so we get the shortest code
> emission, not yours.
>

So as it is now in that case. If it's not my problem but yours, then this
works for me wondrously. :)

The compilers also convert *some* instances of plain multiplication
> followed
> by addition into FMA. That depends on compiler flags, often enough,
> because of
> differences in rounding.
>

I will check if I'm not talking nonsense (as I had a few iterations over
that one), but I can't rely on that to happen magically - so I simply
enforce it at this point with std::fma.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Implicit VFMADD support (Was: Updating x86 SIMD support in Qt)

2022-01-24 Thread Thiago Macieira 
On Monday, 24 January 2022 10:36:41 PST Konstantin Shegunov wrote:
> *My* code, is supposed to fix Qt code at some point, so that's why I'm
> asking. I know I have to do it myself for user code, that's not an issue.

If you're talking about code in Qt, simply use std::fma and it'll do the right 
thing. It becomes my problem to optimise it so we get the shortest code 
emission, not yours.

The compilers also convert *some* instances of plain multiplication followed 
by addition into FMA. That depends on compiler flags, often enough, because of 
differences in rounding.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Implicit VFMADD support (Was: Updating x86 SIMD support in Qt)

2022-01-24 Thread Konstantin Shegunov 
On Mon, Jan 24, 2022 at 7:32 PM Thiago Macieira 
wrote:

> Today, only in the two files with "_avx2" in the name, unless you raise
> the
> CPU architecture yourself while configuring Qt. My proposal is to get that
> on
> Linux by default with the v3 extra build.
>

Yes, this I got from the discussion. However the code in question isn't in
*_avx2. In any case I don't have an objection or an opinion even (about the
original discussion), that default should work for my case, though.

For *your* code, you need to explicitly enable FMA yourself. The changes
> proposed in this thread do not affect user code.
>

*My* code, is supposed to fix Qt code at some point, so that's why I'm
asking. I know I have to do it myself for user code, that's not an issue.


> Both glibc, macOS libSystem, and Windows' ucrtbase have implementations
> using
> the FMA instruction and will detect at runtime which one to use (this was
> the
> *only* place in ucrtbase I found AVX2/FMA code). You're out of luck if
> you're
> using MinGW, though.
>

I suppose that could work, but I'd rather avoid doing the call if I can
help it.


> All compilers tested will use the FMA instruction if you enabled the CPU
> feature, otherwise they'll make a call to the math lbrary's fma() function.


Compare: https://gcc.godbolt.org/z/c5385d5GY (no FMA)
> to: https://gcc.godbolt.org/z/jf3zhsjPf (with FMA)
>

Yes, I already looked at the assembly, which is exactly why I'm asking
about it.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Implicit VFMADD support (Was: Updating x86 SIMD support in Qt)

2022-01-24 Thread Thiago Macieira 
On Monday, 24 January 2022 09:07:16 PST Konstantin Shegunov wrote:
> Related, but somewhat offtopic for the original thread.
> Do we get `-mfma` (or equivalent) added, whenever supported, while we build
> Qt.

Today, only in the two files with "_avx2" in the name, unless you raise the 
CPU architecture yourself while configuring Qt. My proposal is to get that on 
Linux by default with the v3 extra build.

> Is it part of the feature detection? Because I want `std::fma` to emit
> the instruction(s), but I've noticed that in the code I test a bugfix with
> I must force the issue by passing the flag explicitly; even with -O2 I get
> a function call otherwise.

For *your* code, you need to explicitly enable FMA yourself. The changes 
proposed in this thread do not affect user code.

All compilers tested will use the FMA instruction if you enabled the CPU 
feature, otherwise they'll make a call to the math lbrary's fma() function. 
Both glibc, macOS libSystem, and Windows' ucrtbase have implementations using 
the FMA instruction and will detect at runtime which one to use (this was the 
*only* place in ucrtbase I found AVX2/FMA code). You're out of luck if you're 
using MinGW, though.

Compare: https://gcc.godbolt.org/z/c5385d5GY (no FMA)
to: https://gcc.godbolt.org/z/jf3zhsjPf (with FMA)

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Implicit VFMADD support (Was: Updating x86 SIMD support in Qt)

2022-01-24 Thread Konstantin Shegunov 
Related, but somewhat offtopic for the original thread.
Do we get `-mfma` (or equivalent) added, whenever supported, while we build
Qt. Is it part of the feature detection? Because I want `std::fma` to emit
the instruction(s), but I've noticed that in the code I test a bugfix with
I must force the issue by passing the flag explicitly; even with -O2 I get
a function call otherwise.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Updating x86 SIMD support in Qt

2022-01-24 Thread Thiago Macieira 
On Monday, 24 January 2022 05:30:46 PST Konrad Rosenbaum wrote:
> I have absolutely no problem with stuff running faster and more
> efficient on my two laptops (which are significantly more modern), but I
> would have a major problem with it not running at all on my workstation
> that I use for 95% of all my Open Source work. And I would also not like
> my applications to crash on my downstream user's computers (which are on
> average just as old as mine) - every crash means hours of work for
> someone (usually me) to find out what the problem was.

At least i can promise you not to make it a silent crash. Either QtCore or the 
dynamic linker would say it can't run on that machine.

https://code.woboq.org/qt6/qtbase/src/corelib/global/
qsimd.cpp.html#_Z16qDumpCPUFeaturesv

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Updating x86 SIMD support in Qt

2022-01-24 Thread Rui Oliveira 

Hey,

Since Qt has its own Conan/Artifactory setup 
, maybe 
it would be viable to have some different SIMD setups available as 
options for the Qt package?


This would require Conan as a dependency, of course. On most systems 
that means Python (Conan 1.x supports py2 still, the upcoming Conan 2.0 
with all its breaking changes will require py3, iirc), but on Windows 
they have .exe versions available .


I think this would have little impact in the overall build process. 
`conan install qt ` and just point your project to look for Qt 
in ~/.conan... With Qt Creator should be just creating a new kit. If the 
Windows installer for Qt helped with this, even better.



Rui

Às 13:30 de 24/01/2022, Konrad Rosenbaum escreveu:

Hi,

On 23/01/2022 19:39, Thiago Macieira wrote:
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).


Correct. Only a handful of application developers know how to compile 
the entire framework and (esp. on Windows) a lot of them would not 
even have the idea to do it. Some of my Windows-based colleagues would 
panic if I told them to compile their frameworks. I have had paid 
customer projects to help them compile Qt for some OS version where 
binaries were not readily available.


Then there are bastards like me who know perfectly well how to compile 
Qt, who compile all kinds of large programs all the time, but refuse 
to do so with Qt because I am too lazy to tune my build process, I 
think it takes too long and I like the excuse of using "the standard 
configuration"... ;-)


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.


And what makes you think that we stingy, cheap and lazy bastards will 
buy a new computer to replace this outdated piece of scrap metal this 
year when we haven't done so in more than 10 years? ;-)


The cruel fact is that around 2010 computers got so darn efficient 
that you can run a moderately good machine from slightly before 2010 
with minor upgrades to this day and call it "the kid's computer" or 
even your "main workstation" without blushing. I know plenty of people 
(both laymen and CS professionals) who run such old hardware (or 
worse) and don't even notice that it is old - if I hadn't looked it up 
I would have sworn my workstation is less than 6 years old.


[Yes, as someone who's income depends on people buying the newest 
chips the irony of not replacing my own computer in >10 years is not 
entirely lost on me...]


Speaking of LTS: with LTS not available to Open Source users anymore - 
sticking with older versions of Qt is not exactly a good option 
either. Unless I restrict myself to Qt 5.15 until I'm satisfied all my 
downstream users are likely to have bought a new computer (if they are 
as stingy as I am, then Qt7 will be close to being released before 
that happens).



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.


Please please chose v1 as pre-built minimum. There are plenty of v1 
systems out there that need to run Qt applications and plenty of 
developers who will never re-compile Qt.


If the physical appearance of the "please" makes a difference: Pretty 
Please!


I have absolutely no problem with stuff running faster and more 
efficient on my two laptops (which are significantly more modern), but 
I would have a major problem with it not running at all on my 
workstation that I use for 95% of all my Open Source work. And I would 
also not like my applications to crash on my downstream user's 
computers (which are on average just as old as mine) - every crash 
means hours of work for someone (usually me) to find out what the 
problem was.




    Konrad


___
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