[gentoo-science] blas/lapack status

[gentoo-science] blas/lapack status

[Sebastien Fabbro]

Dear all,

While I have been trying to so some ebuilds depending on blas and
lapack, I collected a number of thoughts regarding their implementation
in Gentoo:

* Gentoo doc:
Mentioned in a year-old post on this list, there is this site:
http://www.gentoo.org/proj/en/desktop/science/blas-lapack.xml
Is it still up to date? It is not referred anywhere on the Gentoo web
sites.

* eselect: although eselect seems the way to go, it not yet fully
functional. As I was working on the mkl ebuild, I found out it is not
possible to add a new blas/lapack implementation without changing the
eselect sources. As an example, mkl-7.2 is supported, but not in
portage, and outdated. Also eselect blas/lapack do not yet provide a
mechanism to show library directories and include directories. Something
like "eselect blas show cflags"? Am I missing something?

* Should we really keep those obsolete packages:
  - sci-libs/atlas: now decomposed as sci-libs/blas-atlas and
sci-libs/lapack-atlas
  - sci-libs/blas: redundant with sci-libs/blas-reference
  - sci-libs/lapack: redundant with sci-libs/lapack-reference

* cblas/clapack: as mentioned in a previous post, at least a
virtual/cblas could help (as well as a cblas-reference) ebuild.

* documentation: shouldn't blas/lapack install man pages and quick
references as well as in Fedora (or may be an app-docs/lapack)?

I am ready to help some devs on those issues if any interested.


Sebastien
-- 
gentoo-science@gentoo.org mailing list

Re: [gentoo-science] blas/lapack status

[Adam Piątyszek]

Dear Sebastien, all,

* Sebastien Fabbro [2006-03-20 17:54]:
[...]
> * eselect: although eselect seems the way to go, it not yet fully
> functional. As I was working on the mkl ebuild, I found out it is not
> possible to add a new blas/lapack implementation without changing the
> eselect sources. As an example, mkl-7.2 is supported, but not in
> portage, and outdated. Also eselect blas/lapack do not yet provide a
> mechanism to show library directories and include directories. Something
> like "eselect blas show cflags"? Am I missing something?

I encountered similar limitation when I was preparing an ebuild for 
cblas-reference package (see the following bug-report: 
http://bugs.gentoo.org/show_bug.cgi?id=122958 )

> * Should we really keep those obsolete packages:
>  - sci-libs/atlas: now decomposed as sci-libs/blas-atlas and
> sci-libs/lapack-atlas
>  - sci-libs/blas: redundant with sci-libs/blas-reference
>  - sci-libs/lapack: redundant with sci-libs/lapack-reference

I agree with you Sebastien.
Gentoo Devs: Are there any packages in portage that still use the old 
obsolete atlas/blas/lapack as their dependencies?

> * cblas/clapack: as mentioned in a previous post, at least a
> virtual/cblas could help (as well as a cblas-reference) ebuild.

Are you refering to my post at gentoo-science: "CBLAS support in Gentoo" 
from February 17th, 2006?
Agree one more time: virtual/cblas will be helpful for dependencies in 
"itpp" package, for instance.

> I am ready to help some devs on those issues if any interested.

I am also ready to help with some limited testing and providing ebuilds/fixes.

BR,

/ediap

-- 
-=#=-  Adam Piątyszek - "ediap"    -=#=-  Linux ID: #204648         -=#=-
-=#=-  ediap (at) et.put.poznan.pl -=#=-  JID: ediap (at) chrome.pl -=#=-
-=#=-  http://ediap.prv.pl/        -=#=-  GG: 1157376               -=#=-
-=#=-  PGP key ID: 0x341E22F0      -=#=-  ICQ: 3303291              -=#=-




-- 
gentoo-science@gentoo.org mailing list

Re: [gentoo-science] blas/lapack status

[Markus Dittrich]

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

Hi Sebastien,

Thank you for bringing this up and I apologize for the
somewhat delayed reply. Below are some of my thoughts/comments.

On Mon, 20 Mar 2006, Sebastien Fabbro wrote:
> * Should we really keep those obsolete packages:
>   - sci-libs/atlas: now decomposed as sci-libs/blas-atlas and
> sci-libs/lapack-atlas
>   - sci-libs/blas: redundant with sci-libs/blas-reference
>   - sci-libs/lapack: redundant with sci-libs/lapack-reference

Personally, I have been happily using blas-atlas for 
a while now and would be ok with removing them if nothing
in the tree depends on them directly. Some of the other 
devs might have a different opinion, though.

> 
> * cblas/clapack: as mentioned in a previous post, at least a
> virtual/cblas could help (as well as a cblas-reference) ebuild.
> 

As pointed out by Adam, a cblas-reference ebuild should hit
portage shortly. Before we start pondering the virtual/cblas
more (I am in principle for it) could we identify all the packages 
that can provide it as well as all the ones that can depend on and
benefit from it? 

> * documentation: shouldn't blas/lapack install man pages and quick
> references as well as in Fedora (or may be an app-docs/lapack)?
> 

USE="doc" with blas-atlas installs the quick reference as well
as some other docs. No man pages though. Do you know where the
Fedora guys get them from? I don't see them in the tarballs,
but I might have missed them.

Thanks,
Markus


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

iD8DBQFEIsD8xlRwCwb7k40RAszRAJ9a1NeFevUIL2duJT09dT8IC5CPKQCfTu0E
kuml54nW4iqYBcSAce7LT/8=
=Svh/
-----END PGP SIGNATURE-----
-- 
gentoo-science@gentoo.org mailing list

Re: [gentoo-science] blas/lapack status

[Adam Piątyszek]

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

Hi Sebastien and Markus,

* Sebastien Fabbro [2006-03-23 19:06]:
[...]
> Packages in portage/bugs/overlay which could provide virtual/cblas:
> - blas-atlas
> - acml (although not sure about this one)

ACML does not provide cblas interface. At least the latest ACML 3.0.0.

> - mkl (at least the one in the overlay)

Yes. Versions 7.x.x and 8.x.x provide cblas.

> - cblas-reference

One more package that provides cblas although not blas is sci-libs/gsl.
However its libgslcblas.* works well with blas-reference, blas-atlas and ACML.


That are, at least, packages providing cblas, which I am aware of.

Kind regards,

/ediap


-- 
-=#=-  Adam Piątyszek - "ediap"    -=#=-  Linux ID: #204648         -=#=-
-=#=-  ediap (at) et.put.poznan.pl -=#=-  JID: ediap (at) chrome.pl -=#=-
-=#=-  http://ediap.prv.pl/        -=#=-  GG: 1157376               -=#=-
-=#=-  PGP key ID: 0x341E22F0      -=#=-  ICQ: 3303291              -=#=-


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

Re: [gentoo-science] blas/lapack status

[Donnie Berkholz]

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

Markus Dittrich wrote:
> Hi Sebastien,
> 
> Thank you for bringing this up and I apologize for the
> somewhat delayed reply. Below are some of my thoughts/comments.
> 
> On Mon, 20 Mar 2006, Sebastien Fabbro wrote:
>>> * Should we really keep those obsolete packages:
>>>   - sci-libs/atlas: now decomposed as sci-libs/blas-atlas and
>>> sci-libs/lapack-atlas
>>>   - sci-libs/blas: redundant with sci-libs/blas-reference
>>>   - sci-libs/lapack: redundant with sci-libs/lapack-reference
> 
> Personally, I have been happily using blas-atlas for 
> a while now and would be ok with removing them if nothing
> in the tree depends on them directly. Some of the other 
> devs might have a different opinion, though.

The first time I read this as removing the *-reference packages, but
that can't be what you mean. If you're saying we should remove the old
sci-libs/{blas,lapack}, then I entirely agree assuming *-atlas is stable
on all arches blas/lapack were and nothing still hard deps on them.

If you go to a new-style virtual, you have the option of either having
*-atlas or *-reference stable on the same arches.

Thanks,
Donnie


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

Re: [gentoo-science] blas/lapack status

[Sebastien Fabbro]

Hi Markus,

> Personally, I have been happily using blas-atlas for 
> a while now and would be ok with removing them if nothing
> in the tree depends on them directly.

Same here! Old blas/lapack/atlas packages just bring confusion, 
especially when unmaintained. Packages depending on 
sci-libs/{blas,lapack,atlas}:
sci-geosciences/grass-5.0.2
sci-chemistry/mpqc-2.2.2

> As pointed out by Adam, a cblas-reference ebuild should hit
> portage shortly. Before we start pondering the virtual/cblas
> more (I am in principle for it) could we identify all the packages 
> that can provide it as well as all the ones that can depend on and
> benefit from it? 

Packages in portage/bugs/overlay which could provide virtual/cblas:
- blas-atlas
- acml (although not sure about this one)
- mkl (at least the one in the overlay)
- cblas-reference
Packages which I know could benefit from it:
- scipy
- itpp

I started to look at the module eselect.blas, to make a few changes. But 
before I go further, it would be nice to know if anyone is working on it 
and if the virtual/cblas is the good direction.

> USE="doc" with blas-atlas installs the quick reference as well
> as some other docs. 

I noticed. A lapack-doc could make sense since it is the same for all 
lapack implementations.

 > No man pages though. Do you know where the
> Fedora guys get them from? I don't see them in the tarballs,
> but I might have missed them.

Just rpm2targz'ed the lapack src rpm from
http://download.fedora.redhat.com/pub/fedora/linux/extras/5/SRPMS/
which contains a man pages, quick refs, and a bunch of other patches.
The spec file mentions http://www.netlib.org/lapack/manpages.tgz for the 
man pages. I don't know how Fedora's patches compare to the Gentoo's 
ones, and my last experience on a RH/Fedora computer was 5 years ago.

Cheers,

Sebastien
-- 
gentoo-science@gentoo.org mailing list

Re: [gentoo-science] blas/lapack status

[Markus Dittrich]

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

On Thu, 23 Mar 2006, Donnie Berkholz wrote:
> > Personally, I have been happily using blas-atlas for 
> > a while now and would be ok with removing them if nothing
> > in the tree depends on them directly. Some of the other 
> > devs might have a different opinion, though.
> 
> The first time I read this as removing the *-reference packages, but
> that can't be what you mean. If you're saying we should remove the old
> sci-libs/{blas,lapack}, then I entirely agree assuming *-atlas is stable
> on all arches blas/lapack were and nothing still hard deps on them.
> 
> If you go to a new-style virtual, you have the option of either having
> *-atlas or *-reference stable on the same arches.

Hi Donnie,

I apologize for not being very clear in my response and I was indeed
refering to removing the old sci-libs/{blas,lapack} packages. I'll 
check into the arch issues over the weekend. ppc/ppc64 might be a
problem since they seem to have problems with blas-atlas 
(bug #120775).

Thanks,
Markus


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

iD8DBQFEIulKxlRwCwb7k40RAgHpAJ9YVbwyMta7R0BxGA2G95ywofcBkwCffCly
ioibAWKwWAjZg/F1csqLpv0=
=iF/Q
-----END PGP SIGNATURE-----
-- 
gentoo-science@gentoo.org mailing list

Re: [gentoo-science] blas/lapack status

[Donnie Berkholz]

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

Markus Dittrich wrote:
> I apologize for not being very clear in my response and I was indeed
> refering to removing the old sci-libs/{blas,lapack} packages. I'll 
> check into the arch issues over the weekend. ppc/ppc64 might be a
> problem since they seem to have problems with blas-atlas 
> (bug #120775).

Seen the bug. I keyworded *-reference locally on my ppc (didn't have
hours to get atlas finished) and they work great, fwiw.

Donnie


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

Re: [gentoo-science] blas/lapack status

[Adam Piątyszek]

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

* Adam Piątyszek [2006-03-23 18:55]:
> [...]
>> Packages in portage/bugs/overlay which could provide virtual/cblas:
>> - blas-atlas
>> - acml (although not sure about this one)
> 
> ACML does not provide cblas interface. At least the latest ACML 3.0.0.

It seems that I was wrong here. ACML has C interface for it's BLAS
routines, however it is not compatible with NetLib's, MKL's or ATLAS' CBLAS.
Function names does not have "cblas_" prefix and there are some other
differences.

BR,

/ediap


-- 
-=#=-  Adam Piątyszek - "ediap"    -=#=-  Linux ID: #204648         -=#=-
-=#=-  ediap (at) et.put.poznan.pl -=#=-  JID: ediap (at) chrome.pl -=#=-
-=#=-  http://ediap.prv.pl/        -=#=-  GG: 1157376               -=#=-
-=#=-  PGP key ID: 0x341E22F0      -=#=-  ICQ: 3303291              -=#=-


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

Re: [gentoo-science] blas/lapack status

[Donnie Berkholz]

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

Sebastien Fabbro wrote:
> Dear all,
> 
> While I have been trying to so some ebuilds depending on blas and
> lapack, I collected a number of thoughts regarding their implementation
> in Gentoo:
> 
> * Gentoo doc:
> Mentioned in a year-old post on this list, there is this site:
> http://www.gentoo.org/proj/en/desktop/science/blas-lapack.xml
> Is it still up to date? It is not referred anywhere on the Gentoo web
> sites.

Maybe. =) Feel free to provide a patch to help update it.

> * eselect: although eselect seems the way to go, it not yet fully
> functional. As I was working on the mkl ebuild, I found out it is not
> possible to add a new blas/lapack implementation without changing the
> eselect sources. As an example, mkl-7.2 is supported, but not in
> portage, and outdated. Also eselect blas/lapack do not yet provide a
> mechanism to show library directories and include directories. Something
> like "eselect blas show cflags"? Am I missing something?

I've just decided to start working on this. I wrote an ebuild last night
for Goto BLAS, which provided the motivation to fix this setup.

> * Should we really keep those obsolete packages:
>  - sci-libs/atlas: now decomposed as sci-libs/blas-atlas and
> sci-libs/lapack-atlas
>  - sci-libs/blas: redundant with sci-libs/blas-reference
>  - sci-libs/lapack: redundant with sci-libs/lapack-reference

But take a look at the keywords. Although it does look like we can
remove atlas since {blas,lapack}-atlas are stable on the same keywords,
we can't do so for blas and lapack yet because *-reference aren't stable
on (blas) x86 s390 ppc64 (lapack) x86 or ~arch on (lapack) ppc64.

> * cblas/clapack: as mentioned in a previous post, at least a
> virtual/cblas could help (as well as a cblas-reference) ebuild.

cblas-reference seems to have appeared at some point in the past couple
of months.

> * documentation: shouldn't blas/lapack install man pages and quick
> references as well as in Fedora (or may be an app-docs/lapack)?

Sounds useful. Got a patch?

Thanks,
Donnie


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

Re: [gentoo-science] blas/lapack status

[Sebastien Fabbro]

>> * eselect: although eselect seems the way to go, it not yet fully
>> functional. As I was working on the mkl ebuild, I found out it is not
>> possible to add a new blas/lapack implementation without changing the
>> eselect sources. As an example, mkl-7.2 is supported, but not in
>> portage, and outdated. Also eselect blas/lapack do not yet provide a
>> mechanism to show library directories and include directories. Something
>> like "eselect blas show cflags"? Am I missing something?
> 
> I've just decided to start working on this. I wrote an ebuild last night
> for Goto BLAS, which provided the motivation to fix this setup.

I could contribute or test it if you are not done with it yet.

>> * Should we really keep those obsolete packages:
>>  - sci-libs/atlas: now decomposed as sci-libs/blas-atlas and
>> sci-libs/lapack-atlas
>>  - sci-libs/blas: redundant with sci-libs/blas-reference
>>  - sci-libs/lapack: redundant with sci-libs/lapack-reference
> 
> But take a look at the keywords. Although it does look like we can
> remove atlas since {blas,lapack}-atlas are stable on the same keywords,
> we can't do so for blas and lapack yet because *-reference aren't stable
> on (blas) x86 s390 ppc64 (lapack) x86 or ~arch on (lapack) ppc64.

I took a deeper look at the differences, if it can speed up the
stabilization:
 * The blas-reference has exactly the same code as the older one, so I
guess keywording should be straight forward.
 * The lapack-reference has an extra set of patches. I can only test on
x86 or amd64, which are not the problematic arches in this case.

>> * documentation: shouldn't blas/lapack install man pages and quick
>> references as well as in Fedora (or may be an app-docs/lapack)?
> 
> Sounds useful. Got a patch?

I've just comited some app-doc/{blas,lapack}-docs to the overlay at
http://gentooscience.org,


Sebastien
-- 
gentoo-science@gentoo.org mailing list