Re: atlas, lapack, blas
Hello Camm,
I am glad (and kind of proud ;) ) to receive this email from you. I just
realized with my bug report on maxima that you were still around!
Le vendredi 09 avril 2010 à 12:10 -0400, Camm Maguire a écrit :
> Greetings! I've noticed you've taken up atlas -- great! Thank you so
> much for contributing this vital service to Debian! It appears you've
> done an outstanding job thus far -- congratulations!
>
> I've downloaded your package, and have a few observations and
> recommendations:
>
> 1) The package no longer seems to support runtime blas and lapack
> alternatives via the LD_LIBRARY_PATH environment variable.
Well, update-alternatives intends to replace this behavior....
> Likewise no attempt at configuring ld.so for sane defaults on the running cpu
> are attempted.
I didn't know it was possible before someone pointing this out on my blog.
> ldd /usr/bin/octave-3.2.4|grep blas
> libblas.so.3gf => /usr/lib/libblas.so.3gf (0xb57f9000)
>
> 2) The tester and performance binaries are gone.
My bad. I will put them back in a future upload.
> 3) The package does not appear to ensure that the libraries pass the
> tests before completing, nor provide the timing and testing output for
> the end user to peruse.
>
> 4) There are no more build records, so that the building cpu has to
> support all of the isa extensions shipped by the package. This may
> prove to be no problem from a practical point of view at the present
> time. It definitely was a problem at times in the past.
I will see what I can do for points 3 & 4.
> I haven't looked into this in much detail, and alas am too short of
> time to do so. I apologize for not having enough time to keep up
> with this. I'm in the middle of a book writing project, and have
> underestimated the time required.
No worries.
> I would humbly suggest however that the trio of blas, lapack, and
> atlas continue to be coordinated in a manner similar or superior to
> the past, if at all possible. Ideally, one maintainer or small group
> could handle all three. I am fully aware (from dear experience) that
> this might require more developer time resources than are available.
> However, from the users point of view, it is invaluable to be able to
> run any binary against reference blas or lapack to check for errors,
> as well to monitor performance gains to gauge whether a custom build
> is worth the effort. Not to mention the automatic performance
> enhancement of R, octave, ... without a nightmare of package
> configuration options.
At first, I didn't want to maintain atlas because it is very time
consuming, frustrating (challenging) and painful but I realized that
blas and lapack are kind of coupled with atlas. It is hard to left this
one behind, especially with update-alternatives now ...
I am planning to continue maintaining them (especially because as a core
developer of Scilab, I need them) but I counting on the community to
report me bugs, etc
> Somewhere I recall I have a trial 3.8 package that I could hopefully
> dig up if anyone is interested in addressing these items. I'm also
> quite happy to consult or answer any questions regarding the operation
> of the existing system if needed.
If I knew that before, I would have sent you some emails ;)
Sylvestre
Reply to: