Re: science-optimisation (Was: About the sense of removing -march=native)
On Fri, Feb 10, 2017 at 10:39:48AM +0100, Sébastien Villemot wrote:
> Le jeudi 09 février 2017 à 16:13 +0100, Michael Banck a écrit :
>
> > I think I read the ATLAS README.Debian and found it a bit more
> > convoluted than necessary; in particular, I think it creates binary
> > packages with different names to ones in the official archive (sorry
> > can't check at the moment as I am on crappy dialup)? Probably just
> > bumping the binary package version like we do for backports or binNMUs
> > would be enough.
>
> Actually the package name remains the same as the official package, just
> the version differs (a suffix is appended to the version number).
>
> > A good start would be to both support DEB_BUILD_OPTIONS=custom for
> > generic performance-oriented rebuidls and
> > DEB_CFLAGS_MAINT_APPEND=-march=native for for the -march=native thing.
>
> I’m not sure to understand what a “generic performance-oriented rebuild”
> is. By definition, a performance-oriented rebuild does not create a
> generic binary, but a target-specific one.
I meant generic as possibly doing other stuff[1] as opposed to "just"
adding -march=native via DEB_CFLAGS_MAINT_APPEND.
> However, I agree with you that using DEB_BUILD_OPTIONS rather than a
> custom rule in debian/rules (as currently implemented) would be a nicer
> technical solution. I’m going to open a bug against src:atlas to remind
> myself to make that change for buster.
OK, then maybe it was the custom debian/rules rule that rubbed me, and I
misremembered it as custom package name, sorry.
Thanks for opening a bug!
Michael
[1] Like doing trial-and-error with different code paths for different
set sizes/cache line sizes I think ATLAS is doing; CP2K has the
possiblity to auto-tune one of its internal libraries as well...
Reply to: