Re: science-optimisation (Was: About the sense of removing -march=native)
On Thu, 2017-02-09 at 16:13 +0100, Michael Banck wrote:
> Hi,
>
> On Thu, Feb 09, 2017 at 11:47:59AM +0100, Andreas Tille wrote:
> > Hi Julien,
> >
> > On Wed, Feb 08, 2017 at 06:15:37PM +0100, Julien Puydt wrote:
> > > > I wonder whether we could invent some mechanism that is rebuilding a
> > > > package in postinst and installs the result on the machine instead of a
> > > > pre-build binary. Or we could provide some toolset which enables
> > > > scientists to download a set of source packages and build these after
> > > > re-activating -march=native and move the results in a local repository
> > > > which just needs to be added to sources.list.
> > > >
> > > > Do you consider this as feasible ideas?
> > >
> > > The src:atlas package does something like this :
> > > - the Debian servers ship a generic package ;
> > > - the source package has a special build target for a more optimized
> > > package, which you can then install.
> >
> > I've read README.Debian "Building Optimized Atlas Packages on your ARCH"
> > and think this is pointing very much in the same direction of my second
> > rough idea. For packages that could profit from some optimisation for
> > local machines we could provide a custom target in debian/rules. While
> > I did not yet made up my mind whether it is a good idea to build inside
> > the local environment instead of a pbuilder chroot, this is a detail
> > that could be discussed later.
>
> 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.
>
> 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.
>
> Then again, just testing whether it actually makes a difference for
> end-user applications would be useful as well.
>
> Michael
I was about to suggest something similar using build profiles [1]. They
sound tailored for this sort of alternative build strategies.
[1] https://wiki.debian.org/BuildProfileSpec
Ghis
Reply to: