headers
fbissey | 2 Sep 2011 15:27
Picon

Re: new blas infrastructure and prefix

Quoting Johan Hattne <jhattne <at> lbl.gov>:

> On 30 Aug 2011, at 12:49, fbissey <at> slingshot.co.nz wrote:
>
>> Hi all,
>>
>> So I was looking at the science overlay from my prefix on OS X.
>> And portage wanted me to upgrade my blas/cblas/lapack stack to the
>> new structure. I know they are marked ~x86 and ~amd64 but it doesn't
>> look good considering that I had a working stack in my prefix before.
>>
>> So I may make things a little more prefix friendly (OS X in particular)
>> in the coming days. I am also thinking of adding an ebuild to use the
>> native vectorize framework on OS X, unless someone strongly objects to it.
>
> Hi Francois;
>
> With the CBLAS reference implementations, you may run into a problem 
> with the test suite on Darwin.  I tried to sort this out earlier this 
> year (see 
> http://icl.cs.utk.edu/lapack-forum/archives/lapack/msg00997.html), 
> but I'm not even sure upstream recognises the problem.  Please let me 
> know if at least you can reproduce the issue, and then maybe we can 
> try again to get it fixed.
>
Looking at that thread they don't seem to see a problem. I haven't tackled
cblas-reference yet but I have made an ebuild to use the vectorize framework
from apple on OS X (I'll put it in the overlay soonish) and the test suite for
lapack-reference totaly failed when built with either blas-reference or
vectorize. I am guessing that it must be similar to what you got with
(Continue reading)

Permalink | Reply | 3 comments |
headers
Andrea Arteaga | 2 Sep 2011 20:59
Picon
Gravatar

Re: new blas infrastructure and prefix

Hi Francois.
So, the package lapack-reference is emerged, but the test suite fails, right?
Could you just write a very basic C or Fortran program using a routine
of the LAPACK and compile it with the instruction of pkg-config
lapack, after having emerged lapack-reference and skipped the tests?

Cheers
Andrea
Permalink | Reply | 2 comments |
headers
fbissey | 2 Sep 2011 22:33
Picon

Re: new blas infrastructure and prefix

Quoting Andrea Arteaga <andyspiros <at> gmail.com>:

> Hi Francois.
> So, the package lapack-reference is emerged, but the test suite fails, right?
> Could you just write a very basic C or Fortran program using a routine
> of the LAPACK and compile it with the instruction of pkg-config
> lapack, after having emerged lapack-reference and skipped the tests?
>
I will look into that. For the record, while I didn't run the test for 
the main
prefix tree version (ie not the science overlay) it worked fine as far 
as I can
tell - the sage testsuite runs a number of tests which depend on a working
lapack.

Francois
Permalink | Reply | 0 comments |
headers
Andrea Arteaga | 3 Sep 2011 01:11
Picon
Gravatar

BTL

For the interested on benchmarks, I wrote a proposal for writing a new
version of the BTL. You can read it on my blog: http://wp.me/pzWEm-99

The BTL is a benchmarking library written in C++ and maintained (now)
by the project Eigen. In my opinion it needs some changes, and the
article describes why and which ones. I'm waiting for feedback on the
proposal before coding anything.

Cheers
Andrea Arteaga
Permalink | Reply | 2 comments |
headers
fbissey | 5 Sep 2011 01:47
Picon

Re: new blas infrastructure and prefix

Quoting Andrea Arteaga <andyspiros <at> gmail.com>:

> Hi Francois.
> So, the package lapack-reference is emerged, but the test suite fails, right?
> Could you just write a very basic C or Fortran program using a routine
> of the LAPACK and compile it with the instruction of pkg-config
> lapack, after having emerged lapack-reference and skipped the tests?
>
Probably would work. I had a close look at one of the test programs:

frb15 <at> BlueFerniMac1
~/Desktop/Gentoo/var/tmp/portage/sci-libs/lapack-reference-3.3.1-r1/work/lapack-reference-3.3.1_build/bin
$ ./xeigtstc
dyld: Library not loaded: /Users/frb15/Desktop/Gentoo/usr/lib/libtmglib.dylib
   Referenced from:
/Users/frb15/Desktop/Gentoo/var/tmp/portage/sci-libs/lapack-reference-3.3.1-r1/work/lapack-reference-3.3.1_build/bin/./xeigtstc
   Reason: image not found
Trace/BPT trap
frb15 <at> BlueFerniMac1
~/Desktop/Gentoo/var/tmp/portage/sci-libs/lapack-reference-3.3.1-r1/work/lapack-reference-3.3.1_build/bin
$ ls ../lib/
libreflapack.dylib  libtmglib.dylib

In short it is linked as if it was installed. So it doesn't find one of its
essential library. I am not quite sure how to fix this - in a general fashion.
I think I may be able to do something on OS X. It may actually be easier on a
linux prefix by using LD_LIBRARY_PATH. But the real solution would be for the
test run to have different linking options.

Francois
(Continue reading)

Permalink | Reply | 0 comments |
headers
fbissey | 5 Sep 2011 01:59
Picon

Re: BTL

Quoting Andrea Arteaga <andyspiros <at> gmail.com>:

> For the interested on benchmarks, I wrote a proposal for writing a new
> version of the BTL. You can read it on my blog: http://wp.me/pzWEm-99
>
> The BTL is a benchmarking library written in C++ and maintained (now)
> by the project Eigen. In my opinion it needs some changes, and the
> article describes why and which ones. I'm waiting for feedback on the
> proposal before coding anything.
>
There is a related area that would be of interest to me. It can be put under
benchmarks as well. So far, you have been looking into performance, I 
am curious
about conformance and possibly precision benchmarking.

Does the library behave as it should. What is the accuracy of the result, do
some version of the libraries give more precise results than another
implementation.

This is particularly important to me because of the discussion we 
generate here:
https://github.com/cschwan/sage-on-gentoo/issues/3
and
http://trac.sagemath.org/sage_trac/ticket/10508
where it is clear to me that it is due to something that gives a different
result in cblas from ATLAS-3.9 and it would be good to test this formally.

Francois
(Continue reading)

Permalink | Reply | 1 comment |
headers
Andrea Arteaga | 5 Sep 2011 23:07
Picon
Gravatar

Re: BTL

Hi Francois.

Thanks for the interest. You raised a very good point, which I forgot
to write about. During my GSoC project I also wrote accuracy
benchmarks and this was the only task that the BTL seemd unable to do
without being almost completely rethinked. This actually was a reason
because I decided to start designing a new-style BTL, but finally I
forgot to mention this.

So, now I'm trying to figure out how to make the design as flexible
that new type of benchmarks can be added (accuracy, but also memory
usage, scalability,...).

Cheers
Andrea
Permalink | Reply | 0 comments |
headers
fbissey | 6 Sep 2011 04:23
Picon

Re: new blas infrastructure and prefix

Quoting fbissey <at> slingshot.co.nz:

> Hi all,
>
> So I was looking at the science overlay from my prefix on OS X.
> And portage wanted me to upgrade my blas/cblas/lapack stack to the
> new structure. I know they are marked ~x86 and ~amd64 but it doesn't
> look good considering that I had a working stack in my prefix before.
>
> So I may make things a little more prefix friendly (OS X in particular)
> in the coming days. I am also thinking of adding an ebuild to use the
> native vectorize framework on OS X, unless someone strongly objects to it.

Odd stuff, in the latest gsl from the science overlay someone decided not to
support linking with an external cblas anymore. For some reasons it breaks gsl
on OS X. I have no idea if it is also broken in the main tree if you use
internal gslcblas but I suspect it is. Using an external cblas however worked
fine as far as I can tell.

Francois
Permalink | Reply | 2 comments |
headers
fbissey | 6 Sep 2011 06:39
Picon

Re: new blas infrastructure and prefix

Quoting fbissey <at> slingshot.co.nz:

> Quoting fbissey <at> slingshot.co.nz:
>
>> Hi all,
>>
>> So I was looking at the science overlay from my prefix on OS X.
>> And portage wanted me to upgrade my blas/cblas/lapack stack to the
>> new structure. I know they are marked ~x86 and ~amd64 but it doesn't
>> look good considering that I had a working stack in my prefix before.
>>
>> So I may make things a little more prefix friendly (OS X in particular)
>> in the coming days. I am also thinking of adding an ebuild to use the
>> native vectorize framework on OS X, unless someone strongly objects to it.
>
> Odd stuff, in the latest gsl from the science overlay someone decided not to
> support linking with an external cblas anymore. For some reasons it 
> breaks gsl
> on OS X. I have no idea if it is also broken in the main tree if you use
> internal gslcblas but I suspect it is. Using an external cblas however worked
> fine as far as I can tell.
>
I got that all wrong. I never had another cblas on OS X before. And I now see
that the external cblas option is gone from gsl itself. So why is it not
working anymore on OS X
Permalink | Reply | 1 comment |
headers
fbissey | 9 Sep 2011 04:51
Picon

new blas infrastructure on OS X prefix

Hi,

I have to sadly report that currently the new blas infrastructure from the
science overlay is broken on at least OS X prefix. For example sage doesn't
start with the following message:
sage
----------------------------------------------------------------------
| Sage Version 4.7.2.alpha2, Release Date: 2011-08-24                |
| Type notebook() for the GUI, and license() for information.        |
----------------------------------------------------------------------
**********************************************************************
*                                                                    *
* Warning: this is a prerelease version, and it may be unstable.     *
*                                                                    *
**********************************************************************
---------------------------------------------------------------------------
ImportError                               Traceback (most recent call last)

/Users/frb15/Desktop/Gentoo/usr/lib/python2.7/site-packages/IPython/ipmaker.pyc
in force_import(modname, force_reload)
      61         reload(sys.modules[modname])
      62     else:
---> 63         __import__(modname)
      64
      65

/Users/frb15/Desktop/Gentoo/usr/bin/ipy_profile_sage.py in ()
       5     preparser(True)
       6
----> 7     import sage.all_cmdline
(Continue reading)

Permalink | Reply | 0 comments |

Gmane