Clear Linux Working On AVX2-Optimized Qt Toolkit

[phoronix]

Phoronix: Clear Linux Working On AVX2-Optimized Qt Toolkit

One of the latest package optimizations being worked on within Intel's performance-oriented Clear Linux camp is a faster Qt5 tool-kit...

http://www.phoronix.com/scan.php?page=news_item&px=AVX2-Qt-Optimized-Clear-Linux

[RealNC]

What about AVX1?

[schmidtbag]

I'm a little curious - what happens if you run Clear Linux and these AVX2-optimized packages on something old like a Core2 or Athlon 64? Would it still run normally but just slower, or would it outright fail to run? Because if its the former, why don't all distros optimize their packages? If its the latter, couldn't it be worth emulating these instructions in software?

[Vistaus]

Now let's hope this'll be another thing from Clear Linux that Solus will incorporate

[schmidtbag]

As to why other distros don't do this yet, I suppose that infrastructure and maintenance cost is pretty high.

First of all, thanks for the response. But couldn't Clear just simply post some of their changes downstream to the original devs/source? That way everybody wins. Then again, Clear is sort of an advertisement to Intel, so maybe they wouldn't want to do that, but I otherwise don't really understand what's preventing them from doing so.

[wizard69]

This is great news for the advancement of QT and Clear Linux.

What bothers me everytime you see a software advancement that relies upon new hardware is the whining about old hardware. Come on guys get with the program, old processors are history lessons, not platforms for modern software. Expressing concern about pre AVX2 processors makes about as much sense as whining about not being able to run QT5 on a 6502. 68000, or 80486!

In a nut shell be thankful that Intel is putting in the effort to optimize software for modern processors. Somebody has to lead and eventually this will end up in follow on versions of QT even if Intel isnt the driver.

[carewolf]

Note one problem with lib64/haswell at the moment is that glibc has a hook where it checks specifically for GenuineIntel, so it wouldn't be used by AMD Excavator or Zen, and while they only have 128bit AVX2 microops internally, it would still benefit them greatly over an SSE2 default.

[coder]

At least this AVX2 support would help out Qt3D but likely many other areas too given the performance benefits we have seen out of Advanced Vector Extensions in many other codebases.

I'm not sure about that. As Guest pointed out, AVX2 adds integer support. So, AVX1 would benefit the sort of geometry manipulations you'd tend to find in 3D code. But AVX2 wouldn't really help 3D except in software rasterizers.

I think their goal is probably to accelerate CPU-based 2D rendering and compositing operations.

/usr/lib64/haswell/

This is concerning...

First, isn't Haswell an Intel trademark? The point about GenuineIntel checks is a further concern, here.

IMO, there should just be an ABI name for x86-64 + AVX2 and use that.

[coder]

This is great news for the advancement of QT and Clear Linux.

Really? Why are you so sure? They didn't post any benchmarks, so we don't actually know how much advancement it represents.

What bothers me everytime you see a software advancement that relies upon new hardware is the whining about old hardware. Come on guys get with the program, old processors are history lessons, not platforms for modern software. Expressing concern about pre AVX2 processors makes about as much sense as whining about not being able to run QT5 on a 6502. 68000, or 80486!

No, it's really quite different. 80486 is almost 30 years old, while Ivy Bridge is only 6 years old and still quite decent. Furthermore, even the latest Celeron and Atom-branded CPUs don't support any flavor of AVX.

In a nut shell be thankful that Intel is putting in the effort to optimize software for modern processors. Somebody has to lead and eventually this will end up in follow on versions of QT even if Intel isnt the driver.

I would rather see better compiler extensions for helping GCC and Clang generate more efficient vectorized code.