[gentoo-science] [Fwd: BLAS and CBLAS in Gentoo]

[gentoo-science] [Fwd: BLAS and CBLAS in Gentoo]

[Adam Piątyszek]

[-- Attachment #1: Type: text/plain, Size: 1823 bytes --]

Hi All,

I am forwarding my email to Sebastien regarding the merging of blas- and
cblas-reference into one package. Sebastien accepted this idea, but we
would like to hear your opinions as well, since you are the real users
of scientific libraries in Gentoo.

BR,
/Adam

-------- Wiadomość oryginalna --------
Temat: BLAS and CBLAS in Gentoo
Data: Tue, 10 Jul 2007 09:44:48 +0200
Nadawca: Adam Piątyszek <ediap@et.put.poznan.pl>
Adresat: bicatali@gentoo.org

Hi Sebastien,

How are things going around your new design of scientific libs in
Gentoo? Do you have an overlay, which can be pulled with layman?

BTW, while working with one Debian developer on improving IT++ in
Debian, I realised that we might consider merging blas-reference and
cblas-reference into one package. This is done in many distributions
(Debian, SUSE, PLD Linux, even in Cygwin). I can see mostly advantages
of such a step:

1) cblas-reference provides only bindings to a Fortran BLAS library,
which is usually blas-reference

2) There would be no need to have an extra virtual/cblas.
"eselect blas set reference" for instance should set both blas and cblas
links.

3) People who use BLAS through C interface usually do not mix different
libraries, e.g cblas-reference + BLAS from MKL

4) CBLAS is included in both ATLAS and MKL, besides ACML implements
their own C bindings to BLAS routines (a bit incompatible though)

5) The compilation time of joint blas- & cblas-reference will not be
critical for those who need only Fortran BLAS. Anyway, we can disable
CBLAS in such a joint package with USE="-cblas" flag.

What do you think?

BR,
/ediap


-- 
.:.  Adam Piatyszek - "ediap"       .:.  JID: ediap(at)jabber.org .:.
.:.  ediap(at)users.sourceforge.net .:.  PGP key ID: 0x1F115CCB   .:.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-science] [Fwd: BLAS and CBLAS in Gentoo]

[Markus Dittrich]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, 10 Jul 2007, Adam Pityszek wrote:
> Hi All,
>
> I am forwarding my email to Sebastien regarding the merging of blas- and
> cblas-reference into one package. Sebastien accepted this idea, but we
> would like to hear your opinions as well, since you are the real users
> of scientific libraries in Gentoo.
>
> BR,
> /Adam
>

This sounds like a fine plan to me, particularly since most
blas implementations in portage do provide both blas and cblas
at the same time. In addition, this would render the eselect 
framework less complicated which I find desirable.

cheers,
Markus


- -- 
Markus Dittrich (markusle)
Gentoo Linux Developer
Scientific applications
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGk4AXxlRwCwb7k40RAkdMAKCL3E5bvyMYT0diIe5+DVff5R1ZdgCcDfjs
+7qr5QyIngp7fZWtP3ev5Cs=
=y+8W
-----END PGP SIGNATURE-----
-- 
gentoo-science@gentoo.org mailing list

Re: [gentoo-science] [Fwd: BLAS and CBLAS in Gentoo]

[M. Edward (Ed) Borasky]

Markus Dittrich wrote:
> On Tue, 10 Jul 2007, Adam Pityszek wrote:
>> Hi All,
> 
>> I am forwarding my email to Sebastien regarding the merging of blas- and
>> cblas-reference into one package. Sebastien accepted this idea, but we
>> would like to hear your opinions as well, since you are the real users
>> of scientific libraries in Gentoo.
> 
>> BR,
>> /Adam
> 
> 
> This sounds like a fine plan to me, particularly since most
> blas implementations in portage do provide both blas and cblas
> at the same time. In addition, this would render the eselect framework
> less complicated which I find desirable.
> 
> cheers,
> Markus
> 
> 
> -- Markus Dittrich (markusle)
> Gentoo Linux Developer
> Scientific applications

I think the general scenario for users of BLAS and LAPACK is that they
will be happy with this. However, some people, especially in the
high-performance area, will want to be able to benchmark various
versions (ATLAS, GOTO or chip-specific Intel/AMD) and either static-link
to the winner or dynamic-link to the winner on an individual calling
application basis.

I haven't gotten around to doing that yet, but it's on my list for my
AMD64 dual-core system. I'm not sure the "eselect" facility provides for
this. And a number of packages carry their own BLAS or LAPACK. R is one
of them; in fact

1. R allows you to build a shared library of the BLAS and LAPACK that it
carries, and
2. The R team strongly suggests using the LAPACK that R carries rather
than an external one, and indeed, the "make check-all" tests fail on
some architectures with some external versions of LAPACK. On my Athlon
T-Bird, this happened with the Gentoo lapack-atlas and the R team
slapped me silly when I complained about it on their mailing list. ;)

So as long as I can do all of these things:

1. Choose between static and dynamic linking to BLAS/LAPACK with a USE
flag on any application that allows such a choice,
2. Choose between internal BLAS/LAPACK with a USE flag on any
application that allows such a choice, and
3. Choose between the various versions for the highest performance on an
individual application basis

I'm happy. I think most of the ebuilds are already set up this way, but
again, I haven't had a chance to test with really big problems on my
really big machine yet.
-- 
gentoo-science@gentoo.org mailing list