Re: portable performance engineering

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



You wrote: 

> Dave Love wrote:
>> they'd be rather limited by the compiler options we're supposed to use,
>> that don't include vectorization, so you don't even get the benefit you
>> could from SSE2.  (I've been told off in review for turning that on,
>> though an FPC member has approved it.)
>
> Why don't we enable -ftree-vectorize by default?

I'm happy for it not to be default, as long as sane optimization options
are allowed, and people don't think that they'll get all the benefit of
recent micro-architectures without them.  Note that you're likely to
need unrolling to benefit from vectorization in numerical code anyhow.

> As I wrote elsewhere in this huge thread: just turn the program into a 
> library with a dummy main program.

That will produce technical problems as well as big maintenance ones,
and all this isn't useful without the hwcaps anyhow.  Effort is best put
into engineering the programs.

> You mean the atlas-* subpackages that one has to manually install? That's 
> actually one big reason to NOT use ATLAS, now that we have OpenBLAS that 
> does it right.

The main reason not to use ATLAS is that it's not performant (or wasn't,
last I checked).  As far as I know, OpenBLAS still isn't competitive
with BLIS for avx512, which is the main reason I packaged BLIS and made
shims to subvert slower BLASes.

>> and at least one package (libxsmm) has a minimum requirement of SSE3
>> without complaint.  (I got that down from SSE4 for the benefit of systems
>> we had, though you wouldn't use them for anything CPU-bound.)
>
> Now you have a complaint. :-)
>
> The baseline is SSE2, so the packages are supposed to support systems with 
> nothing beyond SSE2. Just waiting until somebody reports the inevitable 
> SIGILL is not a nice thing to do.
>
> Now, if upstream doesn't support non-SSE3 CPUs, it might be nontrivial to 
> fix the issue. But in principle, a package that requires SSE3 must be 
> considered a bug.

Too bad IMHO.  The probability of anyone running cp2k on that sort of
system in a mode that invokes libxsmm is too small.  Meanwhile, in that
space, I can't get ga rebuilt so LAMMPS will actually run on a
non-Infiniband fabric, and a bunch of other things that need fixing.

Even if people aren't well disposed to engineering, "Everything in the
real world is engineering tradeoffs" (Richard O'Keefe).
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux