[Beowulf] hpl size problems

Mark Hahn hahn at physics.mcmaster.ca
Sat Oct 1 16:05:34 EDT 2005

> It's interesting that you cited ATLAS as an example, BTW, because it is
> a very good one in both directions.

I certainly meant no criticism of ATLAS - it was just the example that came
to mind of a package that clearly does not provide all of a standard (LAPACK).

> What exactly is something like
> ATLAS?  It would require a lot more metadata than I think is currently
> available in order to make it packageable and distributeable in a
> plug-in fashion so that once it were installed all applications that do
> linear algebra would "just use it" where appropriate.  Some of the

precisely - my suggestion is that each interface in a standard be separately
tracked by the per-machine registry.  that means that a package needs to 
tell the registry exactly what it provides (and may conversely query the 
registry to find what it needs.)  this is not much more than a versioned,
standard-based function registry, rather than a versioned, distro-based 
package registry...

> missing metadata involves the identification of the precise architecture
> it was built for; more involves finding the right package to match the

I'm not particularly interested in different architectures, mainly because
there will shortly Be Only One.  but is it really a hard problem?  I'd think
that a single host would normally have a very limited number of arch's 
installed (normally just one, but ia32+x86-64 is not unreasonable.)
a package might offer more than one arch, but it will presumably have 
dependencies on a particular arch.

> architecture.  A third defines precisely what it can replace, and how.

but that's the whole point: a standard exists to provide a canonical
definition of the "whats".  I don't know about your "how" - if I 
install a package that replaces SUS-open-1.0-ia32 with SUS-open-1.1-ia32,
that's my choice.  a package might query the registry for the highest
version of SUS-open-*-ia32, or it might insist on 1.0.  that's up to 
the packager/author.

> I'm not certain about the fourth -- how to make "anything" that might
> use it divert calls so that they do, at least not without making it
> comply with a general ABI.

if I understand you, you're making a distinction between the version 
of a standard that a function implements, versus the version of the function.
it seems like both versions need to be kept, and that normally an app
would choose either the standard-version it's built for and the latest
function-version, or the latest of both.

> This is where I think things NEED to head.  RPM was and is in some ways
> a lovely thing.  However, I personally think it's way short on the
> metadata front, and woefully difficult to extend.  XML offers some hope
> of extendibility without requiring that the final specification be

XML is just formatting.  I don't see that it helps, since it 
doesn't do the hard part (the canonicalization - establishing the 
standard.)  using XML would be perfectly fine, of course, but the issue
(and topic!) is LSB-like efforts and how they help or miss the goal of 
permitting apps to get what they need...

regards, mark.

Beowulf mailing list, Beowulf at beowulf.org
To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf

More information about the Beowulf mailing list