drago01 wrote:
> Only in certain apps, and most of them have handwritten SSE routines
> anyway.
Not all the apps with handwritten SSE routines can detect the CPU at
runtime, there's a significant amount which needs to be built with or
without SSE support at compile time. (This is broken in principle, but it
exists.) In part, this is because GCC only allows SSE intrinsics to be used
if SSE support is enabled, which also allows GCC to use SSE wherever it
feels like it, even in functions where there are no SSE intrinsics. So the
only way to properly support runtime SSE detection is to compile SSE
routines as a separate compilation unit, which not everyone gets right.
(Note that where I wrote "SSE", you can also insert "SSE2", "MMX" or any
other vector instruction set.)
There's also the issue of template-only libraries like Eigen2, which are all
in headers, so they can't do the "separate compilation unit" trick in the
library. Thus, for Eigen2 users, the client program is responsible for
doing the runtime checks and building separate compilation units with SSE2
support enabled. (There's no support for plain SSE or MMX, only for at
least SSE2. There are additional optimized versions for SSE3 and SSSE3.) If
they don't, Eigen2 will just use whatever is enabled in the compiler. Most
programs don't bother doing this. So enabling SSE2 in the compiler will
magically enable the "handwritten" SSE2 optimizations (mostly just making
some templates expand to an intrinsic instead of a loop) in Eigen2.
> Yeah that's why we hide the x86_64 arch from the download page and
> promote x86 everywhere.(attempt to change this failed)
That's a bad thing indeed, and I'm with you there, this needs to change!
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
