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

Re: New atlas packages



On Fri, Jun 06, 2003 at 04:53:26PM -0400, Camm Maguire wrote:
[...]
> As you may know, atlas constructs a free optimized blas (and partial
> lapack) library by carefully timing and searching through various
> algorithms on the building computer.  Several ISA instruction sets are
> supported, many not yet output by gcc at all.  To get good results, it
> is essential that the building machine be quiet during the timing
> process.
> 
> The Debian package can collect the output of a successfully timed
> atlas build, and rerun it during future package builds without
> executing any code on the compiling machine.  This is important given
> our autobuilder setup.  So timing builds only need be performed on new
> upstream releases, which are infrequent.  Timing builds can be very
> cpu intensive and take a long time.

What does this 'timing' actually mean? Is it imperative that the build
of later debian revisions of the same upstream version are built on the
same buildd host? If so, you have a problem on the slower
architectures, such as m68k, where it is very unlikely for the builds of
different versions of the package to happen on the same machine.

Also, it's _impossible_ to guarantee that nothing is executed on a
buildd machine during the build. Autobuilders are partially cron-driven:
'buildd-watcher' regularly checks whether a buildd process is still
running, restarting it as required, also doing various maintenance
tasks, such as purging old, no longer required build trees, rotating
logs, checking for old files, and so on; 'buildd-uploader' regularly
checks a queue on the filesystem, and uploads packages for which a
signed .changes has been mailed to buildd by the admin; and last but
not least, the most things a buildd admin does with its buildd machine,
is give it commands in the form of mails that are sent to it, which
might be processed by buildd-mailer when buildd is still running,
resulting in files being moved around filesystems, files being removed
as a result of katie sending 'ACCEPTED' mails, and so on.

It might also be interesting to note that some buildd machines are not
only used for autobuilding, but have other jobs to perform. Some happen
to be machines on which debian developers have accounts; others, such as
one m68k autobuilder of which I am the admin, perform roles in local,
private networks.

I'm afraid that, if you really need a buildd machine to be doing
absolutely nothing but the timing you refer to, you'll have to set
up a machine for every architecture where you'd like to install these
things, and build the packages yourself.

[...]
> It would greatly assist me if I could get some feedback on the
> following questions.  I'm cc'ing this to the ports lists to solicit
> opinions from the users of the less common platforms as well.  Please
> let me know which of the following most accurately reflects your
> opinion/preference for atlas on your platform of choice:
> 
> 1) No one in their right mind will run atlas on these boxes -- I want
>    my platform excluded from the Architecture: list.

This option should not be given. It is up to our users to decide
whether something is 'useful' on a certain architecture, or not. Please
do not exclude any architecture because you, as a maintainer, think of
it as useless.

Of the other options, I think option #2 or #3 seem to be most prudent
for m68k to me; however, since I am not too familiar with either atlas,
or ISA extentions, I feel I am not very well placed to say which of the
options would be best. As said, I'm afraid none of the autobuilders can
be made as 'quiet' as you request on _any_ architecture.

-- 
Wouter Verhelst
Debian GNU/Linux -- http://www.debian.org
Nederlandstalige Linux-documentatie -- http://nl.linux.org
"An expert can usually spot the difference between a fake charge and a
full one, but there are plenty of dead experts." 
  -- National Geographic Channel, in a documentary about large African beasts.

Attachment: pgp_ERwFZ4vqb.pgp
Description: PGP signature


Reply to: