Bug 202973

Summary:	save final build configuration for sci-libs/blas-atlas, sci-libs/lapack-atlas
Product:	Gentoo Linux	Reporter:	Ariel Poliak <apoliak>
Component:	New packages	Assignee:	Gentoo Science Related Packages <sci>
Status:	RESOLVED INVALID
Severity:	enhancement
Priority:	High
Version:	unspecified
Hardware:	All
OS:	Linux
Whiteboard:
Package list:		Runtime testing required:	---

Description Ariel Poliak 2007-12-22 00:54:47 UTC

The part I dread the most of doing `emerge --update --deep --newuse world` is whenever there is an update for sci-libs/blas-atlas or sci-libs/lapack-atlas, simply because it takes a VERY long time to tune the configuration--the Automatically Tuned part of Automatically Tuned Linear Algebra System.

Given that, my system, and probably many others, are usually under a relatively stable load, it would be great if there was a method for saving the final configuration for these packages to skip the hours-long process of tuning, much like USE="savedconfig" available for sys-apps/busybox

Would this be possible, or did I completely misunderstand how the automatic tuning process works?

Reproducible: Always

Steps to Reproduce:

Comment 1 Markus Dittrich (RETIRED) gentoo-dev

2007-12-22 11:09:25 UTC

Hi Ariel,

Thanks for your note! We are actually already
re-using some of the timings generated by blas-atlas
(they are in /usr/include/atlas) when emerging
lapack-atlas which is why the latter compiles
relatively fast. 

As a matter of fact, atlas comes with a fairly
extensive number of pre-tuned timings for
a variety of CPUs (they are in ATLAS/CONFIG/ARCHS)
and if your machine is among them atlas does not go 
through a full blown tuning process and compiles in
less than two hours even on my 5 year old P4. Hence,
only users with CPUs not covered by the atlas devs end 
up with long compile times. I presume this is the
case for your CPU?

That said, I am not quite sure at the moment
how difficult it would be to implement what you
are envisioning inside our ebuild, but I will have
a look. In any case, obtaining a good set of timings
is more involved than just running a single tuning
session and involves multiple runs with some 
sort of averaging procedure; hence, it would
be much better if upstream could include your
CPU in their list of pre-generated timings. Maybe
you can ping them about it.

Best,
Markus

Comment 2 Ariel Poliak 2007-12-23 07:51:14 UTC

using a P4-32bit, bottleneck must be somewhere else... but now i know it will take a long time...
resolving as invalid - upstream source already includes functionality