Nabble - math-atlas-devel

3.9.18

2009-12-05T18:31:47Z

Guys,

OK, a *lot* later than I'd hoped, I have released 3.9.18. There are
a lot of bug fixes (including a bug in GEMM threading), and I have also
made the QR tuning automatic, since QR is built into ATLAS now. This adds
something like an hour to the install if you don't use arch defs. We may be
able to improve this further later (the QR tuning has already been sped up
quite a bit for most platforms). You can still turn of all lapack tuning
by throwing the -Si latune 0 flag to configure.

ChangeLog is below.

Cheers,
Clint

ATLAS 3.9.18 released 12/05/09, changes from 3.9.17
* Found & fixed error in threaded GEMM
* Fixed bug where lanbtst_pt didn't set NB
* Modified mmksearch_sse.c to try gcc & sse flags if native compiler
can't handle the generated files.
* Rewrote LAPACK/QR NB tuning
- now uses ATLAS/tune/lapack/lanbsrch rather than bin/lanbtst (faster)
- Now done by default
* Numerous errors fixed involving architecture default timing (all levels)
* Modified atlas_install to keep track of times for every part of install,
so we can see where time is spent
* Architectural default related changes:
- Fixed ArchNew target in building arch defs to negate .sum files
- Core264SSE & AMD64K10h64SSE needed negative values in .sum files
- Updated Core264SSE, AMD64K10h64SSE, HAMMER64SSE3 to get new threaded
lapack, and full .sum support

**************************************************************************
** R. Clint Whaley, PhD ** Assist Prof, UTSA ** www.cs.utsa.edu/~whaley **
**************************************************************************

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Math-atlas-devel mailing list
Math-atlas-devel@...
https://lists.sourceforge.net/lists/listinfo/math-atlas-devel

QR & ATLAS 3.9.17

2009-11-15T14:56:15Z

Guys,

I am very happy to announce the release of ATLAS 3.9.17. This is the first
release to feature full support for two projects being worked on by MS
students here at UTSA.

The first you know about from previous releases: the SSE GEMM generator.
However, in prior releases it did not work for CGEMM. Chad Zalkin (the author)
has fixed, and so now ATLAS can generate SSE code in all four precisions. This
produces a noticable speedup on the Core2 (and, I suspect, all SSE3-enabled
Intel chips). I have updated the Core264SSE3 arch defs to use this new
kernel.

Totally new in this release is that ATLAS now has native support for all
QR factorization variants (QR, QL, RQ, LQ). This code was written by
Siju Samuel (based on work by Elmroth & Gustavson), with some help from
Tony Castaldo & myself. ATLAS's new implementation improves over LAPACK
by using recursion within the panel factorization and in the formation of T.
This helps a lot for strongly overdetermined systems, relatively small
problems, or parallel runs. To give you an idea what it does for large
problems (usually its worst case), the following table shows % improvement from
3.9.16 in QR performance, for M=N=2000 for serial, and M=N=4000 for parallel
(AMD is 4-processor, intel is 8):

SREAL DREAL SCPLX DCPLX
core2_1 1% 3% 15% 4%
core2_8 13% 20% 62% 38%
k10h_1 2% 2% 9% 3%
k10h_4 20% 16% 36% 22%

The huge 62% improvement on the 8-processor core2 is so much large than
the AMD machines because Chad's generator speeds the CGEMM kernel up on
intels, in addition to the QR improvements that everyone else got.

The QR routines have both F77 and C interfaces, and for C it supports both
row- and column-major. However, most people will still need to install
LAPACK, because while we have all the factorizations, we are still working
on the higher level GELS, which is how most people call the Householder
factorizations.

We are still working on QR, and this is definitely a BETA release. Please
let me know what performance you see. If you are not on an AMD64K10h64SSE3
or Core264SSE3, then you'll need to retune your QR NB to get maximum
performance (a process that can take hours). If you want to do this,
after your install replace all BLDdir/include/atlas_*GetNB_geqrf.h
with empty files (0 lines, 0 characters), and then issue:
make ILATune pre=d ; make ILATune pre=s ; \
make ILATune pre=z ; make ILATune pre=c
in your BLDdir/bin directory.

I also put in some workarounds for the gcc compiler error that was killing
the windows (and a few unix) folks, and fixed several reported bugs.
The ChangeLog is included below.

Cheers,
Clint

ATLAS 3.9.17 released 11/15/09, changes from 3.9.16
* Chad's SSE GEMM generator now works for CGEMM
- Provides faster (CGEMM) arch defs for Core264SSE3
* Addition of householder factorizations (mostly written by Siju Samuel):
- F77 & C interface, C supports row/col- major
- GEQRF GEQLF GERQF GELQF
- tester is qrtst.c in ATLAS/bin/
- Retuned LAPACK's QR NB arch defs for AMD64K10h64SSE3 & Core264SSE3
* Fixed seg fault in ummsearch caused by mmksearch_sse failure
* Rewrote Write[MM,MV,R1]File to get around gcc bug
* Fixed bugs in ATLAS/src/auxil/[ge,tr]collapse
* Fixed bug in ATLAS/tune/blas/ger/CASES/ATL_zgerk_1x4_sse3.c
* Renamed xatlas_install -> xatlas_build, to get around Windows 7
"security-through-stupidity" misfeature

**************************************************************************
** R. Clint Whaley, PhD ** Assist Prof, UTSA ** www.cs.utsa.edu/~whaley **
**************************************************************************

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Math-atlas-devel mailing list
Math-atlas-devel@...
https://lists.sourceforge.net/lists/listinfo/math-atlas-devel

Re: Building libblas.so.3

2009-11-02T02:17:31Z

On 30/10/09 15:35, Clint Whaley wrote:

> Jess,
>
>> Would it be possible to have the default ATLAS build create the
>> libblas.a and libblas.so libraries? The easy fix is to create a dummy
>> libblas.so that is linked against the required ATLAS libraries,
>> presumably libatlas.so and lib(pt)cblas.so. This is so that several
>> other projects that rely on on BLAS/LAPACK can use ATLAS without changes
>> to their build process.
>>
>> This would be particularly useful for me as, as previously mentioned,
>> we're distributing (internally) a very boring generic i386 SSE3 build of
>> ATLAS in place of the reference BLAS and LAPACK libraries, and this
>> change would allow us to drop ATLAS in easily as a replacement for a lot
>> of scientific libraries and desktop programs that often have very badly
>> written build systems, making it very hard to change anything that they
>> do by default.
>>
>> Would anyone be opposed to this change?
>
> I oppose it on the ground of incompetence! :)

Damn, have you found me out? Oh ..

>
> Building .a's I know how to do, and make work everywhere, and the build
> process is almost the same on all OS. Building dynamic libs is different
> on every machine, fragile, and when anything at all changes, seem to fail
> spuriously. I have spent a lot of effort getting ATLAS able to build the
> dynamic libs as good as it presently does, and yet it presently fails
> about as often as it succeeds.

I guess I'm fairly privileged here in that in my use case the target
system is always some breed of x86 or x86_64 Linux, and with the various
packaging systems specifying dependencies on particular versions of
other libraries and executables (including the compiler) is generally
quite trivial.

> Therefore, I don't see dynamic libs being built by default anytime soon.

I don't need them to be built by default, but a specific target that
created the dummy lib would be nice. I'm really only trying to make my
life easier here though - I can just as easily provide this target for
myself with a patch rolled into the source package.

>
> Now, you seem also to be suggesting combining three libs to one, which
> will not work.

Sorry - I was just being unclear in my notation as I intended to imply
an or with the ( ) around the pt. I'd actually expect to use the
threaded version, rather than the unthreaded one.

> libcblas and libptcblas provide *the same API*, one giving
> threaded and one giving serial interfaces. If you combine them, you
> will lose either the threaded or serial BLAS (depending on the order
> you attempt to combine them). You can see some of this at:
> http://math-atlas.sourceforge.net/errata.html#LINK
>

I thought that was fairly obvious from the description of the ptshared
make target, but I can see how someone might be confused.

> You could build a single blas and ptblas, but then of course you would
> duplicate the huge size of the present libatlas in them if they are supposed
> to be standalone.
>
> Far from library fusion, I am planning further fission: it is very likely
> I will be forced to create a libptlapack for best threaded performance.

In that case, I should be able to get what I want from a 'dummy' library
called libblas.so.3 linked against the threaded BLAS and LAPACK
libraries and against libatlas, sort of like this:

-lptlapack -lptf77blas -lptcblas -latlas

I'll just keep the patch local since it is really probably only wanted
by me for now.

Many thanks

Jess

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Math-atlas-devel mailing list
Math-atlas-devel@...
https://lists.sourceforge.net/lists/listinfo/math-atlas-devel

Re: Building libblas.so.3

2009-10-30T08:35:21Z

Jess,

>Would it be possible to have the default ATLAS build create the
>libblas.a and libblas.so libraries? The easy fix is to create a dummy
>libblas.so that is linked against the required ATLAS libraries,
>presumably libatlas.so and lib(pt)cblas.so. This is so that several
>other projects that rely on on BLAS/LAPACK can use ATLAS without changes
>to their build process.
>
>This would be particularly useful for me as, as previously mentioned,
>we're distributing (internally) a very boring generic i386 SSE3 build of
>ATLAS in place of the reference BLAS and LAPACK libraries, and this
>change would allow us to drop ATLAS in easily as a replacement for a lot
>of scientific libraries and desktop programs that often have very badly
>written build systems, making it very hard to change anything that they
>do by default.
>
>Would anyone be opposed to this change?

I oppose it on the ground of incompetence! :)

Building .a's I know how to do, and make work everywhere, and the build
process is almost the same on all OS. Building dynamic libs is different
on every machine, fragile, and when anything at all changes, seem to fail
spuriously. I have spent a lot of effort getting ATLAS able to build the
dynamic libs as good as it presently does, and yet it presently fails
about as often as it succeeds. Therefore, I don't see dynamic libs
being built by default anytime soon.

Now, you seem also to be suggesting combining three libs to one, which
will not work. libcblas and libptcblas provide *the same API*, one giving
threaded and one giving serial interfaces. If you combine them, you
will lose either the threaded or serial BLAS (depending on the order
you attempt to combine them). You can see some of this at:
http://math-atlas.sourceforge.net/errata.html#LINK

You could build a single blas and ptblas, but then of course you would
duplicate the huge size of the present libatlas in them if they are supposed
to be standalone.

Far from library fusion, I am planning further fission: it is very likely
I will be forced to create a libptlapack for best threaded performance.

Cheers,
Clint

**************************************************************************
** R. Clint Whaley, PhD ** Assist Prof, UTSA ** www.cs.utsa.edu/~whaley **
**************************************************************************

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Math-atlas-devel mailing list
Math-atlas-devel@...
https://lists.sourceforge.net/lists/listinfo/math-atlas-devel

Building libblas.so.3

2009-10-30T06:31:38Z

Would it be possible to have the default ATLAS build create the
libblas.a and libblas.so libraries? The easy fix is to create a dummy
libblas.so that is linked against the required ATLAS libraries,
presumably libatlas.so and lib(pt)cblas.so. This is so that several
other projects that rely on on BLAS/LAPACK can use ATLAS without changes
to their build process.

This would be particularly useful for me as, as previously mentioned,
we're distributing (internally) a very boring generic i386 SSE3 build of
ATLAS in place of the reference BLAS and LAPACK libraries, and this
change would allow us to drop ATLAS in easily as a replacement for a lot
of scientific libraries and desktop programs that often have very badly
written build systems, making it very hard to change anything that they
do by default.

Would anyone be opposed to this change?

Jess

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Math-atlas-devel mailing list
Math-atlas-devel@...
https://lists.sourceforge.net/lists/listinfo/math-atlas-devel

Help with Windows

2009-10-19T08:33:55Z

Guys,

OK, a couple of people at least have expressed a willingness to help, so
I have created a couple of things to aid in this.

The first thing I have done is create a forum for people using ATLAS on
windows to exchange information, as well as for me to ask questions of
people who have more Windows-fu than I. If you know something about
Windows, I hope you will monitor the forum:
https://sourceforge.net/projects/math-atlas/forums/forum/1026734
And reply to any questions that you know.

I have opened up some topics for things that I want to know (mostly newbie
Windows questions to make it quicker for me to get working on ATLAS rather than
Windows stuff when investigating ATLAS on Windows problems). Please post
any relavent info you have!

If there are other things you have had to do to get things working, please open
up additional topics.

The other thing I have done to allow for external help is to open up a
special ATLAS on Windows support tracker:
https://sourceforge.net/tracker/?group_id=23725&atid=1202777

As support questions come in, any that involve unsolved Windows-specific
problems will be moved here. What I would like to ask of you windows-savvy
users is that you monitor this tracker list, and post any workarounds/fixes
that you know to user-reported problems. Even in the absence of a fix,
having multiple people confirm the bug, and perhaps give additional info,
can be very helpful in finding the problem quickly.

As I said before, probably at least half of all Windows problems are already
solved by other users; I think the separate tracker will just make it easier
for people to find and support these windows-specific issues.

So, please scope the new forum and sign up to monitor it if you are a
Windows user (I am monitoring it), add your $.02 to any topic, and
create any useful topics you know about, as well as scoping the new
support tracker.

If there are additional things I can do to help with Windows collaboration,
let me know (possibly on the windows forum!).

Many thanks,
Clint

**************************************************************************
** R. Clint Whaley, PhD ** Assist Prof, UTSA ** www.cs.utsa.edu/~whaley **
**************************************************************************

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Math-atlas-devel mailing list
Math-atlas-devel@...
https://lists.sourceforge.net/lists/listinfo/math-atlas-devel

ATLAS 3.9.16

2009-10-17T12:45:52Z

Guys,

I have released ATLAS 3.9.16. It is mainly a bunch of bug fixes on top of .15,
but also has new arch defs that provide some lapack speedup on my machines
at least.

Cheers,
Clint

ATLAS 3.9.16 released 10/17/09 (bugfix release), changes from 3.9.15
* Fixed bugs in mmksearch_sse.c for machines w/o SSE3
* Fixed errors in C2F preventing full lapack install
* Fixed error in atlas_install trying to open wrong filename in latune
* Fixed error in mmsearch's FindNoCopyNB where latency computed incorrectly
* Numerous errors related to new architectural default handling
* New architectural defaults for:
- AMD64K10h64SSE3
- Core264SSE3
- Corei764SSE3

**************************************************************************
** R. Clint Whaley, PhD ** Assist Prof, UTSA ** www.cs.utsa.edu/~whaley **
**************************************************************************

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Math-atlas-devel mailing list
Math-atlas-devel@...
https://lists.sourceforge.net/lists/listinfo/math-atlas-devel

HELP with ATLAS & Windows

2009-10-16T12:11:08Z

Guys,

I really need some help with ATLAS on windows. I am pretty overwhelmed
just trying to keep the package moving towards stable and answer unix
support questions. I am hoping the community can help me with Windows
support and development, where I believe ATLAS is falling further and
further behind.

I'm a far from expert windows guy, and there seems always to be windows-
specific problems. More than half the time when a fix is found for a
windows-specific problem, it is pointed out to me by a windows user.

What I would like to do is create a Wiki about installing ATLAS on windows, and
have all you guys who successfully install on windows post any
tricks/techniques there, as well as links to prebuilt binaries, etc., for other
users. I would also like to open up a support tracker, perhaps with more open
admin-style stuff, specifically for windows issues. Also, perhaps a mailing
list for windows stuff.

Are any of you who use ATLAS on windows willing to contribute towards
this idea?

It is not only that I need help in providing Windows support, but also
that I could use a forum to ask questions to help me improve Windows
support. For instance, I've been asked to help adapt the ATLAS
installer to MinGW. I tried to do this once, and spent 4 hours failing
to install a working MinGW, and had to return to problems I could make
progress on. I'd like to be able to correspond with someone who has already
done this, so I can spend my time working on the ATLAS code. There have been a
bunch of things like this: I have a bunch of noobie questions in regards to
something under windows, and a very small amount of time to address a
windows-specific issue, and since I don't know anybody to ask the windows
questions to, I never even get to try to figure out the ATLAS problem.

So, before I take the time to create a wiki, amiling list, etc., I'd like
to see who would contribute in this effort. Please e-mail me if you are
interested in helping me improve ATLAS on windows.

Thanks,
Clint

**************************************************************************
** R. Clint Whaley, PhD ** Assist Prof, UTSA ** www.cs.utsa.edu/~whaley **
**************************************************************************

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Math-atlas-devel mailing list
Math-atlas-devel@...
https://lists.sourceforge.net/lists/listinfo/math-atlas-devel

3.9.15

2009-10-11T07:22:14Z

Guys,

I've been quiet recently; I have been overwhelmed at work. However, I have
been working every spare moment on ATLAS. The task I've been working
on is changing the ATLAS matmul search to incorporate a new code generator!

Chad Zalkin (student at UTSA working with me on his MS) created a SSE-enabled
code generator for ATLAS this summer, and I have just finished getting
ATLAS's framework to utilize it. The code generator uses gcc/icc intrinsics
to vectorize the main GEMM kernel. The SSE generator's main purpose is to
ease ATLAS's reliance on hand-tuning for vectorized kernels. On some
machines, it provides speedup over existing hand-tuned kernels (eg., my
Core2 system gets about 8% speedup for single precision). I haven't
tracked it down yet, but the code generator seems to never provide speedup
on the AMD systems I have access to, but does seem to help Intel systems.
I'm guessing gcc is generating an instruction stream that intel likes but
that is not OK on AMDs, but it'll have to be looked into . . .

Chad is still working on the code generator: right now it does not work
for single precision complex; I tend not to work very hard on hand-tuning
single precision, so performance should probably go up even further when
this is fixed.

I have not provided architectural defaults for the new search, so the
install can be quite long in 3.9.15. However, I thought people would
be interested to see the new code generator; if you want a faster install,
just continue using 3.9.14 for now.

I have also started the process of rationalizing ATLAS's search. ATLAS
is now built so that others can easily plug in their own searches and/or
code generators into the ATLAS framework. I still need to produce some
documentation explaining how to do this, but you can find most things
you need in ATLAS/include/atlas_mm[parse,testtime].h. The other nice
thing that I think people will like is that I have quietened down the
GEMM search. All the compilation and so forth goes to /dev/null, so
that it is easier to see the timing results as they are searched . . .

Cheers,
Clint

ATLAS 3.9.15 released 10/10/09, changes from 3.9.14
* Addition of Chad Zalkin's SSE GEMM generator to ATLAS
* Support for external searches and use of standard matmul search routs in:
- include/atlas_mmparse.h
- include/atlas_mmtesttime.h
* Numerous search changes to incorporate above in ATLAS matmul install
- Changed matmul install to be much quieter

**************************************************************************
** R. Clint Whaley, PhD ** Assist Prof, UTSA ** www.cs.utsa.edu/~whaley **
**************************************************************************

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Math-atlas-devel mailing list
Math-atlas-devel@...
https://lists.sourceforge.net/lists/listinfo/math-atlas-devel

Re: *** No rule to make target `libptf77blas.a', needed by `libptf77blas.so'. Stop.

2009-10-09T01:18:19Z

On 08/10/09 14:51, Sascha Manns wrote:

> Hi Jesscia,
>
> Am Donnerstag 08 Oktober 2009 15:08:52 wrote Jessica Jones:
>> This is an error from make, telling you that it doesn't know how to
>> create libptf77blas.a, based on the information in the Makefiles. This
>> is required for the 'make ptshared' step, so you're failing to build the
>> threaded, shared libraries.
>>
>> It is hard to say what is causing it without seeing more detail. I
>> would have to dig through the source at this point to see what is
>> happening. Are you building using rpmbuild or mock for this?
> Yes, i'm using rpmbuild.
> BTW: In the Patch i've found:
> libptf77blas.so : libptf77blas.a
> - ld $(LDFLAGS) -shared -soname $(LIBINSTdir)/libptf77blas.so \
> - -o libptf77blas.so -rpath-link $(LIBINSTdir) \
> + ld $(LDFLAGS) -shared \
> + -soname $(LIBINSTdir)/libptf77blas.so.$(so_ver_major) \
> + -o libptf77blas.so.$(so_ver) \
> + -rpath-link $(LIBINSTdir) \
> --whole-archive libptf77blas.a --no-whole-archive $(F77SYSLIB)
> + ln -s ./libptf77blas.so.$(so_ver) libptf77blas.so.$(so_ver_major)
> + ln -s ./libptf77blas.so.$(so_ver) libptf77blas.so
> So normally he must find the Rule...
>

Well, it doesn't fail when I build it in mock, so presumably there is
something different with your environment (mock runs rpmbuild within a
chroot, to keep things clean)?

If you go through the build steps yourself manually, do you see the same
error?

Jess

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Math-atlas-devel mailing list
Math-atlas-devel@...
https://lists.sourceforge.net/lists/listinfo/math-atlas-devel

Re: *** No rule to make target `libptf77blas.a', needed by `libptf77blas.so'. Stop.

2009-10-08T06:51:34Z

Hi Jesscia,

Am Donnerstag 08 Oktober 2009 15:08:52 wrote Jessica Jones:
> This is an error from make, telling you that it doesn't know how to
> create libptf77blas.a, based on the information in the Makefiles. This
> is required for the 'make ptshared' step, so you're failing to build the
> threaded, shared libraries.
>
> It is hard to say what is causing it without seeing more detail. I
> would have to dig through the source at this point to see what is
> happening. Are you building using rpmbuild or mock for this?
Yes, i'm using rpmbuild.
BTW: In the Patch i've found:
libptf77blas.so : libptf77blas.a
- ld $(LDFLAGS) -shared -soname $(LIBINSTdir)/libptf77blas.so \
- -o libptf77blas.so -rpath-link $(LIBINSTdir) \
+ ld $(LDFLAGS) -shared \
+ -soname $(LIBINSTdir)/libptf77blas.so.$(so_ver_major) \
+ -o libptf77blas.so.$(so_ver) \
+ -rpath-link $(LIBINSTdir) \
--whole-archive libptf77blas.a --no-whole-archive $(F77SYSLIB)
+ ln -s ./libptf77blas.so.$(so_ver) libptf77blas.so.$(so_ver_major)
+ ln -s ./libptf77blas.so.$(so_ver) libptf77blas.so
So normally he must find the Rule...

--
Sincerely Yours

Sascha Manns
openSUSE Member
openSUSE Ambassador
openSUSE Build Service
openSUSE Marketing Team
Maifeldstrasse 10
D-56 727 Mayen

Phone: +49 2651 4014045
Email: saigkill@...
Web: http://saschamanns.gulli.to
Blog: http://saigkill.wordpress.com
Twitter: http://twitter.com/saigkill
ClaimID: http://claimid.com/saigkill

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Math-atlas-devel mailing list
Math-atlas-devel@...
https://lists.sourceforge.net/lists/listinfo/math-atlas-devel

Re: *** No rule to make target `libptf77blas.a', needed by `libptf77blas.so'. Stop.

2009-10-08T06:08:52Z

On 08/10/09 13:39, Sascha Manns wrote:

> Hello Mates,
>
> first of all i would like to thank Jesica Jones for helping me (Spec & Patch).
> Now the Buildprocess is longer :-)
> ATM i'm getting:
>
> + make ptshared
> rm -f libatlas.so* liblapack.so* \
> lib*blas.so* libclapack.so*
> make libatlas.so libptf77blas.so libf77blas.so \
> libptcblas.so libcblas.so liblapack.so
> make[1]: Entering directory `/usr/src/packages/BUILD/ATLAS/x86_64_base/lib'
> ld -melf_x86_64 -shared \
> -soname
> /usr/src/packages/BUILDROOT/libatlas3-3.9.14-1.x86_64/usr/lib64/atlas/libatlas.so.3
> \
> -o libatlas.so.3.0 \
> -rpath-link
> /usr/src/packages/BUILDROOT/libatlas3-3.9.14-1.x86_64/usr/lib64/atlas \
> --whole-archive libatlas.a --no-whole-archive -lc -lm
> ln -s ./libatlas.so.3.0 libatlas.so.3
> ln -s ./libatlas.so.3.0 libatlas.so
> make[1]: *** No rule to make target `libptf77blas.a', needed by
> `libptf77blas.so'. Stop.
> make[1]: Leaving directory `/usr/src/packages/BUILD/ATLAS/x86_64_base/lib'
> make: *** [ptshared] Error 2
> error: Bad exit status from /var/tmp/rpm-tmp.NuktA1 (%build)
>
> Has anyone an Idea to fix it?
>

This is an error from make, telling you that it doesn't know how to
create libptf77blas.a, based on the information in the Makefiles. This
is required for the 'make ptshared' step, so you're failing to build the
threaded, shared libraries.

It is hard to say what is causing it without seeing more detail. I
would have to dig through the source at this point to see what is
happening. Are you building using rpmbuild or mock for this?

Jess

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Math-atlas-devel mailing list
Math-atlas-devel@...
https://lists.sourceforge.net/lists/listinfo/math-atlas-devel

*** No rule to make target `libptf77blas.a', needed by `libptf77blas.so'. Stop.

2009-10-08T05:39:34Z

Hello Mates,

first of all i would like to thank Jesica Jones for helping me (Spec & Patch).
Now the Buildprocess is longer :-)
ATM i'm getting:

+ make ptshared
rm -f libatlas.so* liblapack.so* \
lib*blas.so* libclapack.so*
make libatlas.so libptf77blas.so libf77blas.so \
libptcblas.so libcblas.so liblapack.so
make[1]: Entering directory `/usr/src/packages/BUILD/ATLAS/x86_64_base/lib'
ld -melf_x86_64 -shared \
-soname
/usr/src/packages/BUILDROOT/libatlas3-3.9.14-1.x86_64/usr/lib64/atlas/libatlas.so.3
\
-o libatlas.so.3.0 \
-rpath-link
/usr/src/packages/BUILDROOT/libatlas3-3.9.14-1.x86_64/usr/lib64/atlas \
--whole-archive libatlas.a --no-whole-archive -lc -lm
ln -s ./libatlas.so.3.0 libatlas.so.3
ln -s ./libatlas.so.3.0 libatlas.so
make[1]: *** No rule to make target `libptf77blas.a', needed by
`libptf77blas.so'. Stop.
make[1]: Leaving directory `/usr/src/packages/BUILD/ATLAS/x86_64_base/lib'
make: *** [ptshared] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.NuktA1 (%build)

Has anyone an Idea to fix it?
--
Sincerely Yours

Sascha Manns
openSUSE Member
openSUSE Ambassador
openSUSE Build Service
openSUSE Marketing Team
Maifeldstrasse 10
D-56 727 Mayen

Phone: +49 2651 4014045
Email: saigkill@...
Web: http://saschamanns.gulli.to
Blog: http://saigkill.wordpress.com
Twitter: http://twitter.com/saigkill
ClaimID: http://claimid.com/saigkill

[atlas-bladudd_shared.patch]

diff -rau ATLAS.o/makes/Make.lib ATLAS/makes/Make.lib --- ATLAS.o/makes/Make.lib 2009-04-07 15:11:39.000000000 +0100 +++ ATLAS/makes/Make.lib 2009-08-04 11:57:46.000000000 +0100 @@ -3,6 +3,9 @@ # # override with libatlas.so only when atlas is built to one lib # +so_ver_major=3 +so_ver = $(so_ver_major).0 + DYNlibs = liblapack.so libf77blas.so libcblas.so libatlas.so PTDYNlibs = liblapack.so libptf77blas.so libptcblas.so libatlas.so CDYNlibs = liblapack.so libcblas.so libatlas.so @@ -36,47 +39,82 @@ # The following commands are to build dynamic/shared objects on Linux # =================================================================== ptshared : - - rm -f libatlas.so liblapack.so + - rm -f libatlas.so* liblapack.so* \ + lib*blas.so* libclapack.so* $(MAKE) libatlas.so libptf77blas.so libf77blas.so \ libptcblas.so libcblas.so liblapack.so shared : - - rm -f libatlas.so liblapack.so + - rm -f libatlas.so* liblapack.so* $(MAKE) libatlas.so libf77blas.so libcblas.so liblapack.so cptshared : - - rm -f libatlas.so libclapack.so + - rm -f libatlas.so* libclapack.so* $(MAKE) libatlas.so libclapack.so libptcblas.so libcblas.so cshared : - - rm -f libatlas.so libclapack.so + - rm -f libatlas.so* libclapack.so* $(MAKE) libatlas.so libclapack.so libcblas.so libatlas.so : libatlas.a - ld $(LDFLAGS) -shared -soname $(LIBINSTdir)/libatlas.so -o libatlas.so \ + ld $(LDFLAGS) -shared \ + -soname $(LIBINSTdir)/libatlas.so.$(so_ver_major) \ + -o libatlas.so.$(so_ver) \ -rpath-link $(LIBINSTdir) \ --whole-archive libatlas.a --no-whole-archive -lc $(LIBS) + ln -s ./libatlas.so.$(so_ver) libatlas.so.$(so_ver_major) + ln -s ./libatlas.so.$(so_ver) libatlas.so + liblapack.so : liblapack.a - ld $(LDFLAGS) -shared -soname $(LIBINSTdir)/liblapack.so \ - -o liblapack.so -rpath-link $(LIBINSTdir) --whole-archive \ + ld $(LDFLAGS) -shared \ + -soname $(LIBINSTdir)/liblapack.so.$(so_ver_major) \ + -o liblapack.so.$(so_ver) \ + -rpath-link $(LIBINSTdir) --whole-archive \ liblapack.a --no-whole-archive $(F77SYSLIB) + ln -s ./liblapack.so.$(so_ver) liblapack.so.$(so_ver_major) + ln -s ./liblapack.so.$(so_ver) liblapack.so + libclapack.so : libclapack.a - ld $(LDFLAGS) -shared -soname $(LIBINSTdir)/libclapack.so \ - -o libclapack.so -rpath-link $(LIBINSTdir) \ + ld $(LDFLAGS) -shared \ + -soname $(LIBINSTdir)/libclapack.so.$(so_ver_major) \ + -o libclapack.so.$(so_ver) \ + -rpath-link $(LIBINSTdir) \ --whole-archive libclapack.a --no-whole-archive -lc $(LIBS) + ln -s ./libclapack.so.$(so_ver) libclapack.so.$(so_ver_major) + ln -s ./libclapack.so.$(so_ver) libclapack.so + libptf77blas.so : libptf77blas.a - ld $(LDFLAGS) -shared -soname $(LIBINSTdir)/libptf77blas.so \ - -o libptf77blas.so -rpath-link $(LIBINSTdir) \ + ld $(LDFLAGS) -shared \ + -soname $(LIBINSTdir)/libptf77blas.so.$(so_ver_major) \ + -o libptf77blas.so.$(so_ver) \ + -rpath-link $(LIBINSTdir) \ --whole-archive libptf77blas.a --no-whole-archive $(F77SYSLIB) + ln -s ./libptf77blas.so.$(so_ver) libptf77blas.so.$(so_ver_major) + ln -s ./libptf77blas.so.$(so_ver) libptf77blas.so + libf77blas.so : libf77blas.a - ld $(LDFLAGS) -shared -soname $(LIBINSTdir)/libf77blas.so \ - -o libf77blas.so -rpath-link $(LIBINSTdir) \ + ld $(LDFLAGS) -shared \ + -soname $(LIBINSTdir)/libf77blas.so.$(so_ver_major) \ + -o libf77blas.so.$(so_ver) \ + -rpath-link $(LIBINSTdir) \ --whole-archive libf77blas.a --no-whole-archive $(F77SYSLIB) + ln -s ./libf77blas.so.$(so_ver) libf77blas.so.$(so_ver_major) + ln -s ./libf77blas.so.$(so_ver) libf77blas.so + libptcblas.so : libptcblas.a - ld $(LDFLAGS) -shared -soname $(LIBINSTdir)/libptcblas.so \ - -o libptcblas.so -rpath-link $(LIBINSTdir) \ + ld $(LDFLAGS) -shared \ + -soname $(LIBINSTdir)/libptcblas.so.$(so_ver_major) \ + -o libptcblas.so.$(so_ver) \ + -rpath-link $(LIBINSTdir) \ --whole-archive libptcblas.a --no-whole-archive -lc $(LIBS) + ln -s ./libptcblas.so.$(so_ver) libptcblas.so.$(so_ver_major) + ln -s ./libptcblas.so.$(so_ver) libptcblas.so + libcblas.so : libcblas.a - ld $(LDFLAGS) -shared -soname $(LIBINSTdir)/libcblas.so \ - -o libcblas.so -rpath-link $(LIBINSTdir) \ + ld $(LDFLAGS) -shared \ + -soname $(liBINSTdir)/libcblas.so.$(so_ver_major) \ + -o libcblas.so.$(so_ver) \ + -rpath-link $(LIBINSTdir) \ --whole-archive libcblas.a --no-whole-archive -lc $(LIBS) + ln -s ./libcblas.so.$(so_ver) libcblas.so.$(so_ver_major) + ln -s ./libcblas.so.$(so_ver) libcblas.so # # Builds one shared lib from all ATLAS files

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Math-atlas-devel mailing list
Math-atlas-devel@...
https://lists.sourceforge.net/lists/listinfo/math-atlas-devel

Re: atlas 3.9.14: GEMV TUNE Build Error

2009-10-07T05:43:38Z

On 07/10/09 12:12, Jessica Jones wrote:

> On 07/10/09 09:29, Jessica Jones wrote:
>> On 06/10/09 19:05, Sascha Manns wrote:
>>> Hello Mates,
>>>
>>> i've tried to Build the 3.9.14 Version. But i get:
>>>
>>> STAGE 2-3-5: GEMV TUNE
>>> make -f Makefile INSTALL_LOG/zMVRES pre=z 2>&1 | ./xatlas_tee
>>> INSTALL_LOG/zMVTUNE.LOG
>>> make[1]: *** [build] Error 255
>>> make[1]: Leaving directory `/usr/src/packages/BUILD/ATLAS/x86_64_base'
>>> make: *** [build] Error 2
>>> error: Bad exit status from /var/tmp/rpm-tmp.DkaQoT (%build)
>>>
>>> Anyone know how to fix it?
>> Sascha
>>
>> I don't get this error, but I'll make my SPEC file and SRPM available to
>> you shortly - it is currently going through koji and the only bit I need
>> to check now is that all the built files are included.
>>
>
> You can now get the spec file that we are using here:
>
> http://people.bath.ac.uk/cs1jrj/software/atlas.spec
>
> Please be aware that (a) the build is not optimised - it is only
> intended to be used for development and for some packages that would
> otherwise be using the reference BLAS - and (b) I have not tested it
> yet, only ensured that it builds. The results from the make tests look
> promising though, so I am optimistic so far.
>
> If you can wait for a little while (I am off to lunch now) I will make
> sure that the SRPM is up there too.

Here it is:
http://people.bath.ac.uk/cs1jrj/software/atlas-3.9.14-1.cb1.1.src.rpm

This builds in koji against RHEL 5.3. I don't know enough about how
SUSE compares to say whether or not it will build there also.

It is probably worth noting that the current GCC on RHEL 5.3 is 4.1.x.
4.3.x is available as the package gcc43 (also gcc43-gfortran, etc), but
I've not built using that. I'm in two minds about whether to supply the
static libraries, so I've not stopped them being built with -fPIC. (I'd
prefer it if the users we are supplying this to linked dynamically with
ATLAS so that at least when they copy their binaries to our HPC they are
using the properly optimised version.)

Jess

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Math-atlas-devel mailing list
Math-atlas-devel@...
https://lists.sourceforge.net/lists/listinfo/math-atlas-devel

Re: atlas 3.9.14: GEMV TUNE Build Error

2009-10-07T04:12:04Z

On 07/10/09 09:29, Jessica Jones wrote:

>
> On 06/10/09 19:05, Sascha Manns wrote:
>> Hello Mates,
>>
>> i've tried to Build the 3.9.14 Version. But i get:
>>
>> STAGE 2-3-5: GEMV TUNE
>> make -f Makefile INSTALL_LOG/zMVRES pre=z 2>&1 | ./xatlas_tee
>> INSTALL_LOG/zMVTUNE.LOG
>> make[1]: *** [build] Error 255
>> make[1]: Leaving directory `/usr/src/packages/BUILD/ATLAS/x86_64_base'
>> make: *** [build] Error 2
>> error: Bad exit status from /var/tmp/rpm-tmp.DkaQoT (%build)
>>
>> Anyone know how to fix it?
>
> Sascha
>
> I don't get this error, but I'll make my SPEC file and SRPM available to
> you shortly - it is currently going through koji and the only bit I need
> to check now is that all the built files are included.
>

You can now get the spec file that we are using here:

http://people.bath.ac.uk/cs1jrj/software/atlas.spec

Please be aware that (a) the build is not optimised - it is only
intended to be used for development and for some packages that would
otherwise be using the reference BLAS - and (b) I have not tested it
yet, only ensured that it builds. The results from the make tests look
promising though, so I am optimistic so far.

If you can wait for a little while (I am off to lunch now) I will make
sure that the SRPM is up there too.

Jess

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Math-atlas-devel mailing list
Math-atlas-devel@...
https://lists.sourceforge.net/lists/listinfo/math-atlas-devel

Re: atlas 3.9.14: GEMV TUNE Build Error

2009-10-07T01:29:54Z

On 06/10/09 19:05, Sascha Manns wrote:

> Hello Mates,
>
> i've tried to Build the 3.9.14 Version. But i get:
>
> STAGE 2-3-5: GEMV TUNE
> make -f Makefile INSTALL_LOG/zMVRES pre=z 2>&1 | ./xatlas_tee
> INSTALL_LOG/zMVTUNE.LOG
> make[1]: *** [build] Error 255
> make[1]: Leaving directory `/usr/src/packages/BUILD/ATLAS/x86_64_base'
> make: *** [build] Error 2
> error: Bad exit status from /var/tmp/rpm-tmp.DkaQoT (%build)
>
> Anyone know how to fix it?

Sascha

I don't get this error, but I'll make my SPEC file and SRPM available to
you shortly - it is currently going through koji and the only bit I need
to check now is that all the built files are included.

Jess

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Math-atlas-devel mailing list
Math-atlas-devel@...
https://lists.sourceforge.net/lists/listinfo/math-atlas-devel

atlas 3.9.14: GEMV TUNE Build Error

2009-10-06T11:05:03Z

Hello Mates,

i've tried to Build the 3.9.14 Version. But i get:

STAGE 2-3-5: GEMV TUNE
make -f Makefile INSTALL_LOG/zMVRES pre=z 2>&1 | ./xatlas_tee
INSTALL_LOG/zMVTUNE.LOG
make[1]: *** [build] Error 255
make[1]: Leaving directory `/usr/src/packages/BUILD/ATLAS/x86_64_base'
make: *** [build] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.DkaQoT (%build)

Anyone know how to fix it?
--
Sincerely Yours

Sascha Manns
openSUSE Member
openSUSE Ambassador
openSUSE Build Service
openSUSE Marketing Team
Maifeldstrasse 10
D-56 727 Mayen

Phone: +49 2651 4014045
Email: saigkill@...
Web: http://saschamanns.gulli.to
Blog: http://saigkill.wordpress.com
Twitter: http://twitter.com/saigkill
ClaimID: http://claimid.com/saigkill

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Math-atlas-devel mailing list
Math-atlas-devel@...
https://lists.sourceforge.net/lists/listinfo/math-atlas-devel

Re: Reimplement lapack

2009-10-06T08:46:20Z

On 06/10/09 16:14, Clint Whaley wrote:

> Jess,
>
>> Are the instructions in the INSTALL.txt that is supplied with the 3.9.14
>> tarball accurate? Particularly the section entitled: "NOTE ON BUILDING
>> A FULL LAPACK LIBRARY". I'm a little confused as to exactly how much
>> building of LAPACK is now included in ATLAS without my having to do
>> anything.
>
> Good catch: the instructions in INSTALL.txt are out of date. I believe the
> instructions in ATLAS/doc/atlas_install.pdf are up-to-date. As long
> as you use the --with-netlib-lapack-tarfile= configure flag, ATLAS
> should handle the install of the mixed ATLAS/LAPACK library for you.

Thanks, I'll try that.

Jess

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Math-atlas-devel mailing list
Math-atlas-devel@...
https://lists.sourceforge.net/lists/listinfo/math-atlas-devel

Re: Reimplement lapack

2009-10-06T08:14:57Z

Jess,

>Are the instructions in the INSTALL.txt that is supplied with the 3.9.14
>tarball accurate? Particularly the section entitled: "NOTE ON BUILDING
>A FULL LAPACK LIBRARY". I'm a little confused as to exactly how much
>building of LAPACK is now included in ATLAS without my having to do
>anything.

Good catch: the instructions in INSTALL.txt are out of date. I believe the
instructions in ATLAS/doc/atlas_install.pdf are up-to-date. As long
as you use the --with-netlib-lapack-tarfile= configure flag, ATLAS
should handle the install of the mixed ATLAS/LAPACK library for you.

Thanks,
Clint

**************************************************************************
** R. Clint Whaley, PhD ** Assist Prof, UTSA ** www.cs.utsa.edu/~whaley **
**************************************************************************

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Math-atlas-devel mailing list
Math-atlas-devel@...
https://lists.sourceforge.net/lists/listinfo/math-atlas-devel

Re: Reimplement lapack

2009-10-06T07:35:51Z

On 04/09/09 23:28, Clint Whaley wrote:

> Guys,
>
>> Can we reimplement in configure --with-netlib
>> lapack=%{buildroot}%{_libdir}/liblapack_pic.a?
>
> All things are possible. I was trying to simplify my life by eliminating it,
> however. In particular, people tend to build lapack with incompatible flags,
> and then write in for help because ATLAS doesn't work. I therefore thought I'd
> simplify the framework by not having this option anymore, and also cut down the
> user help requests by always having ATLAS build it.
>
> Does anyone else really want this option? I suppose if enough knowledgable
> people use it, I could add it back, and perhaps not mention it in the
> docs . . .
>

Are the instructions in the INSTALL.txt that is supplied with the 3.9.14
tarball accurate? Particularly the section entitled: "NOTE ON BUILDING
A FULL LAPACK LIBRARY". I'm a little confused as to exactly how much
building of LAPACK is now included in ATLAS without my having to do
anything.

Thanks

Jess

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Math-atlas-devel mailing list
Math-atlas-devel@...
https://lists.sourceforge.net/lists/listinfo/math-atlas-devel

Re: Reimplement lapack

2009-09-13T16:20:39Z

Hi Jessica,

Am Sonntag 06 September 2009 21:10:08 wrote Sascha Manns:

> Am Sonntag 06 September 2009 20:37:09 wrote cs1jrj@...:
> > >> For those who are wondering, we package them as RPMs because it makes
> > >> upgrading and so on much easier when you have the support of the
> > >> package management system. There are a huge number of scientific
> > >> packages installed on our clusters for various uses.
> > >
> > > Hmm. Maybe i can show your Spec? I think i can try your Solution...
> >
> > You can, but if you don't mind I'd prefer to wait for a little while?
>
> It would be great :-)

Just an reminder...

--
Sincerely Yours

Sascha Manns
openSUSE Member
openSUSE Ambassador
openSUSE Build Service
openSUSE Marketing Team
Maifeldstrasse 10
D-56 727 Mayen

Phone: +49 2651 4014045
Email: saigkill@...
Web: http://saschamanns.gulli.to
Blog: http://saigkill.wordpress.com
Twitter: http://twitter.com/saigkill
ClaimID: http://claimid.com/saigkill

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Math-atlas-devel mailing list
Math-atlas-devel@...
https://lists.sourceforge.net/lists/listinfo/math-atlas-devel

Re: Reimplement lapack

2009-09-08T10:43:58Z

On 08/09/09 17:31, Clint Whaley wrote:
> Guys,
>
> I'm not following all the discussions here (beginning of semester & all),
> but it sounded like some of you are not using the ATLAS-built LAPACK.
> If you build LAPACK yourself from netlib, you will get substantially less
> performance than if you use the ATLAS built one, particularly for LU, LLt,
> and QR (probably roughly in that order).

We realise that, but certainly in our case, this is something that is
fine given where it is being used - we're using a fairly generic
(actually SSE3, rather than SSE2 as previously stated) ATLAS kernel for
x86 anyway, rather than tuning it for the specific machine. This is for
people developing their code on their desktops, where performance is not
important but being able to make sure that the code compiles when you
are without access to the HPC facilities is quite useful, and it still
out-performs the reference implementation, which is nice. For this
reason we are using instead of the reference BLAS just to be nice to the
ordinary users, who may not even know what BLAS is, but need it for
various pieces of software that they use.

What we are doing is packaging it for distribution across a range of
desktops, rather than for an HPC. The HPCs are treated quite
differently, as performance is definitely an issue here! We also
package it there, but in a less neat and tidy way so as to keep the
original LAPACK and the other tuning, which are specific to that
machine. It just makes life easier when upgrading or uninstalling to
have the software packages managed by the system.

> ATLAS has recursive LU and LLt
> that are superior to LAPACK's staticly blocked algorithms, and empirically
> tunes the static block factor for QR (sounds like some of you are doing this
> for your LAPACK libs).

We are, I don't know if anyone else is. I only found out about it
through a paper that you wrote a while back, which showed how a LAPACK
intended for use with GotoBLAS might be tuned using tools provided by
ATLAS. It was/is really useful BTW, thanks. :)

I hope you feel less concerned/confused now? Many of the terms were
specific to the building of RPMs, something that doesn't really work all
that well when you want to actually care about performance, as the
target tends to be i686 or x86_64 at best.

Jess

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Math-atlas-devel mailing list
Math-atlas-devel@...
https://lists.sourceforge.net/lists/listinfo/math-atlas-devel

Re: Reimplement lapack

2009-09-08T09:31:20Z

Guys,

I'm not following all the discussions here (beginning of semester & all),
but it sounded like some of you are not using the ATLAS-built LAPACK.
If you build LAPACK yourself from netlib, you will get substantially less
performance than if you use the ATLAS built one, particularly for LU, LLt,
and QR (probably roughly in that order). ATLAS has recursive LU and LLt
that are superior to LAPACK's staticly blocked algorithms, and empirically
tunes the static block factor for QR (sounds like some of you are doing this
for your LAPACK libs). We are presently working on a hybrid recursive/static
blocked QR which will eventually give native support for the QR variants,
which should again be noticibly faster than even tuned static blocking.
We also have special parallel algorithms that are going to improve LU and
QR in parallel substantially (not in there yet, though).

Even the stable release has the superior LU and Cholesky. You should
probably see the largest performance differences for large parallel
factorizations.

Regards,
Clint

**************************************************************************
** R. Clint Whaley, PhD ** Assist Prof, UTSA ** www.cs.utsa.edu/~whaley **
**************************************************************************

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Math-atlas-devel mailing list
Math-atlas-devel@...
https://lists.sourceforge.net/lists/listinfo/math-atlas-devel

Re: Reimplement lapack

2009-09-06T12:12:25Z

saigkill@... sent an e-mail to the math-atlas-devel@..., cs1jrj@... address, received: Sun 06 Sep 2009 15:12:25

Please be advised that cs1jrj@... is no longer with Algorithmics.

Kindly make a note of this for future reference.

Regards,

Algorithmics Postmaster

This is an automated reply.

This email and any files transmitted with it are confidential and proprietary to Algorithmics Incorporated and its affiliates ("Algorithmics"). If received in error, use is prohibited. Please destroy, and notify sender. Sender does not waive confidentiality or privilege. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. Algorithmics does not accept liability for any errors or omissions. Any commitment intended to bind Algorithmics must be reduced to writing and signed by an authorized signatory.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Math-atlas-devel mailing list
Math-atlas-devel@...
https://lists.sourceforge.net/lists/listinfo/math-atlas-devel

Re: Reimplement lapack

2009-09-06T12:10:08Z

Am Sonntag 06 September 2009 20:37:09 wrote cs1jrj@...:

> Quoting Sascha Manns <saigkill@...>:
> >> >> I assume you are building it as an RPM then?
> >> >
> >> > Yes ...
> >> >
> >> >> We also do this, but I've
> >> >> been cheating by getting ATLAS to build it for me, then stealing the
> >> >> build flags suggested by ATLAS to create the LAPACK RPM, which we
> >> >> keep
> >> >
> >> > How do you do this? You create lapack rpm before creating ATLAS?
> >>
> >> Yes. We are building everything via koji (basically we have our own
> >> RedHat rebuild, much like CentOS, but with certain things, such as GCC,
> >> updated to something newer due to various site requirements that we
> >> have).
> >>
> >> What we do is not as neat as I would like, but it requires fewer
> >> modifications. We only build ATLAS for a generic SSE2-capable processor
> >> unless building for our central cluster, which itself runs Scientific
> >> Linux and for which we build packages also via koji.
> >>
> >> Basically, outside of the build system when first packaging ATLAS, I
> >> usually build ATLAS, then look through the build and configure logs for
> >> the flags passed to LAPACK when it builds that. As you know, you do not
> >> have to use all the files built by the %build section of your RPM spec
> >> file, so we install the LAPACK RPM separately to ATLAS and then ignore
> >> the LAPACK libraries later built by ATLAS itself. Our ATLAS RPM then
> >> requires the LAPACK RPM, named rather unimaginatively for ATLAS as
> >> lapack-atlas, but provides BLAS. Does that make sense? We also package
> >> GotoBLAS in a similar way, but not for general distribution, only for
> >> the various clusters that we have (all of them have some RedHat-based
> >> distribution on them, be it Scientific Linux or Rocks).
> >>
> >> For those who are wondering, we package them as RPMs because it makes
> >> upgrading and so on much easier when you have the support of the package
> >> management system. There are a huge number of scientific packages
> >> installed on our clusters for various uses.
> >
> > Hmm. Maybe i can show your Spec? I think i can try your Solution...
>
> You can, but if you don't mind I'd prefer to wait for a little while?

It would be great :-)

--
Sincerely Yours

Sascha Manns
openSUSE Ambassador
openSUSE Build Service
openSUSE Marketing Team
Maifeldstrasse 10
D-56 727 Mayen

Phone: +49 2651 4014045
Fax: +49 3222 1764729
Email: saigkill@...
Web: http://saschamanns.gulli.to
Blog: http://saigkill.wordpress.com

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Math-atlas-devel mailing list
Math-atlas-devel@...
https://lists.sourceforge.net/lists/listinfo/math-atlas-devel

Re: Reimplement lapack

2009-09-06T11:37:09Z

Quoting Sascha Manns <saigkill@...>:

>> >> I assume you are building it as an RPM then?
>> >
>> > Yes ...
>> >
>> >> We also do this, but I've
>> >> been cheating by getting ATLAS to build it for me, then stealing the
>> >> build flags suggested by ATLAS to create the LAPACK RPM, which we keep
>> >
>> > How do you do this? You create lapack rpm before creating ATLAS?
>>
>> Yes. We are building everything via koji (basically we have our own
>> RedHat rebuild, much like CentOS, but with certain things, such as GCC,
>> updated to something newer due to various site requirements that we have).
>>
>> What we do is not as neat as I would like, but it requires fewer
>> modifications. We only build ATLAS for a generic SSE2-capable processor
>> unless building for our central cluster, which itself runs Scientific
>> Linux and for which we build packages also via koji.
>>
>> Basically, outside of the build system when first packaging ATLAS, I
>> usually build ATLAS, then look through the build and configure logs for
>> the flags passed to LAPACK when it builds that. As you know, you do not
>> have to use all the files built by the %build section of your RPM spec
>> file, so we install the LAPACK RPM separately to ATLAS and then ignore the
>> LAPACK libraries later built by ATLAS itself. Our ATLAS RPM then
>> requires the LAPACK RPM, named rather unimaginatively for ATLAS as
>> lapack-atlas, but provides BLAS. Does that make sense? We also package
>> GotoBLAS in a similar way, but not for general distribution, only for the
>> various clusters that we have (all of them have some RedHat-based
>> distribution on them, be it Scientific Linux or Rocks).
>>
>> For those who are wondering, we package them as RPMs because it makes
>> upgrading and so on much easier when you have the support of the package
>> management system. There are a huge number of scientific packages
>> installed on our clusters for various uses.
> Hmm. Maybe i can show your Spec? I think i can try your Solution...
>

You can, but if you don't mind I'd prefer to wait for a little while?
RHEL 5.4 just came out so we are in the middle of a massive
upgrade/rebuild cycle. It is also on my todo list, now that ATLAS is
building the LAPACK for us, to create the LAPACK packages for use with
ATLAS from the one spec file when ATLAS is built. I think this method
would be a lot cleaner than having configure flags gleaned from ATLAS
hand-written into the LAPACK spec file (although this is not
preventable for GotoBLAS).

Jess

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Math-atlas-devel mailing list
Math-atlas-devel@...
https://lists.sourceforge.net/lists/listinfo/math-atlas-devel

Re: Reimplement lapack

2009-09-06T11:23:17Z

saigkill@... sent an e-mail to the math-atlas-devel@..., cs1jrj@... address, received: Sun 06 Sep 2009 14:23:17

Please be advised that cs1jrj@... is no longer with Algorithmics.

Kindly make a note of this for future reference.

Regards,

Algorithmics Postmaster

This is an automated reply.

This email and any files transmitted with it are confidential and proprietary to Algorithmics Incorporated and its affiliates ("Algorithmics"). If received in error, use is prohibited. Please destroy, and notify sender. Sender does not waive confidentiality or privilege. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. Algorithmics does not accept liability for any errors or omissions. Any commitment intended to bind Algorithmics must be reduced to writing and signed by an authorized signatory.

Re: Reimplement lapack

2009-09-06T11:18:21Z

Am Sonntag 06 September 2009 20:01:17 wrote J R Jones:

> On Sun, 6 Sep 2009, Sascha Manns wrote:
> > Hi Jessica,
> >
> > Am Sonntag 06 September 2009 15:26:43 wrote Jessica Jones:
> >> On 04/09/09 23:44, Sascha Manns wrote:
> >>> Am Samstag 05 September 2009 00:28:07 wrote Clint Whaley:
> >>>> Guys,
> >>>>
> >>>>> Can we reimplement in configure --with-netlib
> >>>>> lapack=%{buildroot}%{_libdir}/liblapack_pic.a?
> >>>>
> >>>> All things are possible. I was trying to simplify my life by
> >>>> eliminating it, however. In particular, people tend to build lapack
> >>>> with incompatible flags, and then write in for help because ATLAS
> >>>> doesn't work. I therefore thought I'd simplify the framework by not
> >>>> having this option anymore, and also cut down the user help requests
> >>>> by always having ATLAS build it.
> >>>
> >>> Maybe we can give both options. So everyone can choose, what he wants.
> >>> The Problem is, we have an own lapack Package in out Buildservice. I
> >>> add all relevant Packages to my chroot (buildroot). Then i can give
> >>> configure the Path to the needed Lib.
> >>> In the present status i must add an Tarfile from an Program, who exists
> >>> already an own Package.
> >>> Do you know what i mean?
> >>
> >> I assume you are building it as an RPM then?
> >
> > Yes ...
> >
> >> We also do this, but I've
> >> been cheating by getting ATLAS to build it for me, then stealing the
> >> build flags suggested by ATLAS to create the LAPACK RPM, which we keep
> >
> > How do you do this? You create lapack rpm before creating ATLAS?
>
> Yes. We are building everything via koji (basically we have our own
> RedHat rebuild, much like CentOS, but with certain things, such as GCC,
> updated to something newer due to various site requirements that we have).
>
> What we do is not as neat as I would like, but it requires fewer
> modifications. We only build ATLAS for a generic SSE2-capable processor
> unless building for our central cluster, which itself runs Scientific
> Linux and for which we build packages also via koji.
>
> Basically, outside of the build system when first packaging ATLAS, I
> usually build ATLAS, then look through the build and configure logs for
> the flags passed to LAPACK when it builds that. As you know, you do not
> have to use all the files built by the %build section of your RPM spec
> file, so we install the LAPACK RPM separately to ATLAS and then ignore the
> LAPACK libraries later built by ATLAS itself. Our ATLAS RPM then
> requires the LAPACK RPM, named rather unimaginatively for ATLAS as
> lapack-atlas, but provides BLAS. Does that make sense? We also package
> GotoBLAS in a similar way, but not for general distribution, only for the
> various clusters that we have (all of them have some RedHat-based
> distribution on them, be it Scientific Linux or Rocks).
>
> For those who are wondering, we package them as RPMs because it makes
> upgrading and so on much easier when you have the support of the package
> management system. There are a huge number of scientific packages
> installed on our clusters for various uses.

Hmm. Maybe i can show your Spec? I think i can try your Solution...

--
Sincerely Yours

Sascha Manns
openSUSE Ambassador
openSUSE Build Service
openSUSE Marketing Team
Maifeldstrasse 10
D-56 727 Mayen

Phone: +49 2651 4014045
Fax: +49 3222 1764729
Email: saigkill@...
Web: http://saschamanns.gulli.to
Blog: http://saigkill.wordpress.com

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Math-atlas-devel mailing list
Math-atlas-devel@...
https://lists.sourceforge.net/lists/listinfo/math-atlas-devel

Re: Reimplement lapack

2009-09-06T11:01:17Z

On Sun, 6 Sep 2009, Sascha Manns wrote:

> Hi Jessica,
>
> Am Sonntag 06 September 2009 15:26:43 wrote Jessica Jones:
>> On 04/09/09 23:44, Sascha Manns wrote:
>>> Am Samstag 05 September 2009 00:28:07 wrote Clint Whaley:
>>>> Guys,
>>>>
>>>>> Can we reimplement in configure --with-netlib
>>>>> lapack=%{buildroot}%{_libdir}/liblapack_pic.a?
>>>>
>>>> All things are possible. I was trying to simplify my life by
>>>> eliminating it, however. In particular, people tend to build lapack
>>>> with incompatible flags, and then write in for help because ATLAS
>>>> doesn't work. I therefore thought I'd simplify the framework by not
>>>> having this option anymore, and also cut down the user help requests by
>>>> always having ATLAS build it.
>>>
>>> Maybe we can give both options. So everyone can choose, what he wants.
>>> The Problem is, we have an own lapack Package in out Buildservice. I add
>>> all relevant Packages to my chroot (buildroot). Then i can give configure
>>> the Path to the needed Lib.
>>> In the present status i must add an Tarfile from an Program, who exists
>>> already an own Package.
>>> Do you know what i mean?
>>
>> I assume you are building it as an RPM then?
> Yes ...
>
>> We also do this, but I've
>> been cheating by getting ATLAS to build it for me, then stealing the
>> build flags suggested by ATLAS to create the LAPACK RPM, which we keep
> How do you do this? You create lapack rpm before creating ATLAS?
>

Yes. We are building everything via koji (basically we have our own
RedHat rebuild, much like CentOS, but with certain things, such as GCC,
updated to something newer due to various site requirements that we have).

What we do is not as neat as I would like, but it requires fewer
modifications. We only build ATLAS for a generic SSE2-capable processor
unless building for our central cluster, which itself runs Scientific
Linux and for which we build packages also via koji.

Basically, outside of the build system when first packaging ATLAS, I
usually build ATLAS, then look through the build and configure logs for
the flags passed to LAPACK when it builds that. As you know, you do not
have to use all the files built by the %build section of your RPM spec
file, so we install the LAPACK RPM separately to ATLAS and then ignore the
LAPACK libraries later built by ATLAS itself. Our ATLAS RPM then
requires the LAPACK RPM, named rather unimaginatively for ATLAS as
lapack-atlas, but provides BLAS. Does that make sense? We also package
GotoBLAS in a similar way, but not for general distribution, only for the
various clusters that we have (all of them have some RedHat-based
distribution on them, be it Scientific Linux or Rocks).

For those who are wondering, we package them as RPMs because it makes
upgrading and so on much easier when you have the support of the package
management system. There are a huge number of scientific packages
installed on our clusters for various uses.

Jess

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Math-atlas-devel mailing list
Math-atlas-devel@...
https://lists.sourceforge.net/lists/listinfo/math-atlas-devel

Re: Reimplement lapack

2009-09-06T09:26:08Z

saigkill@... sent an e-mail to the math-atlas-devel@..., j.r.jones@... address, received: Sun 06 Sep 2009 12:26:08

Please be advised that j.r.jones@... is no longer with Algorithmics.

Kindly make a note of this for future reference.

Regards,

Algorithmics Postmaster

This is an automated reply.

This email and any files transmitted with it are confidential and proprietary to Algorithmics Incorporated and its affiliates ("Algorithmics"). If received in error, use is prohibited. Please destroy, and notify sender. Sender does not waive confidentiality or privilege. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. Algorithmics does not accept liability for any errors or omissions. Any commitment intended to bind Algorithmics must be reduced to writing and signed by an authorized signatory.

Re: Reimplement lapack

2009-09-06T09:24:54Z

Hi Jessica,

Am Sonntag 06 September 2009 15:26:43 wrote Jessica Jones:

> On 04/09/09 23:44, Sascha Manns wrote:
> > Am Samstag 05 September 2009 00:28:07 wrote Clint Whaley:
> >> Guys,
> >>
> >>> Can we reimplement in configure --with-netlib
> >>> lapack=%{buildroot}%{_libdir}/liblapack_pic.a?
> >>
> >> All things are possible. I was trying to simplify my life by
> >> eliminating it, however. In particular, people tend to build lapack
> >> with incompatible flags, and then write in for help because ATLAS
> >> doesn't work. I therefore thought I'd simplify the framework by not
> >> having this option anymore, and also cut down the user help requests by
> >> always having ATLAS build it.
> >
> > Maybe we can give both options. So everyone can choose, what he wants.
> > The Problem is, we have an own lapack Package in out Buildservice. I add
> > all relevant Packages to my chroot (buildroot). Then i can give configure
> > the Path to the needed Lib.
> > In the present status i must add an Tarfile from an Program, who exists
> > already an own Package.
> > Do you know what i mean?
>
> I assume you are building it as an RPM then?

Yes ...

> We also do this, but I've
> been cheating by getting ATLAS to build it for me, then stealing the
> build flags suggested by ATLAS to create the LAPACK RPM, which we keep
How do you do this? You create lapack rpm before creating ATLAS?

--
Sincerely Yours

Sascha Manns
openSUSE Ambassador
openSUSE Build Service
openSUSE Marketing Team
Maifeldstrasse 10
D-56 727 Mayen

Phone: +49 2651 4014045
Fax: +49 3222 1764729
Email: saigkill@...
Web: http://saschamanns.gulli.to
Blog: http://saigkill.wordpress.com

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Math-atlas-devel mailing list
Math-atlas-devel@...
https://lists.sourceforge.net/lists/listinfo/math-atlas-devel

Re: Reimplement lapack

2009-09-06T06:27:36Z

j.r.jones@... sent an e-mail to the math-atlas-devel@..., saigkill@... address, received: Sun 06 Sep 2009 09:27:36

Please be advised that math-atlas-devel@..., saigkill@... is no longer with Algorithmics.

Kindly make a note of this for future reference.

Regards,

Algorithmics Postmaster

This is an automated reply.

This email and any files transmitted with it are confidential and proprietary to Algorithmics Incorporated and its affiliates ("Algorithmics"). If received in error, use is prohibited. Please destroy, and notify sender. Sender does not waive confidentiality or privilege. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. Algorithmics does not accept liability for any errors or omissions. Any commitment intended to bind Algorithmics must be reduced to writing and signed by an authorized signatory.

Re: Reimplement lapack

2009-09-06T06:26:43Z

On 04/09/09 23:44, Sascha Manns wrote:

> Am Samstag 05 September 2009 00:28:07 wrote Clint Whaley:
>> Guys,
>>
>>> Can we reimplement in configure --with-netlib
>>> lapack=%{buildroot}%{_libdir}/liblapack_pic.a?
>> All things are possible. I was trying to simplify my life by eliminating
>> it, however. In particular, people tend to build lapack with incompatible
>> flags, and then write in for help because ATLAS doesn't work. I therefore
>> thought I'd simplify the framework by not having this option anymore, and
>> also cut down the user help requests by always having ATLAS build it.
> Maybe we can give both options. So everyone can choose, what he wants.
> The Problem is, we have an own lapack Package in out Buildservice. I add all
> relevant Packages to my chroot (buildroot). Then i can give configure the Path
> to the needed Lib.
> In the present status i must add an Tarfile from an Program, who exists
> already an own Package.
> Do you know what i mean?
>

I assume you are building it as an RPM then? We also do this, but I've
been cheating by getting ATLAS to build it for me, then stealing the
build flags suggested by ATLAS to create the LAPACK RPM, which we keep
separate from one tuned for GotoBLAS by hand using the tools provided
helpfully by ATLAS (yes this is a bit confusing, but it works very well).

Jess

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Math-atlas-devel mailing list
Math-atlas-devel@...
https://lists.sourceforge.net/lists/listinfo/math-atlas-devel

Re: Reimplement lapack

2009-09-04T15:44:18Z

Am Samstag 05 September 2009 00:28:07 wrote Clint Whaley:

> Guys,
>
> >Can we reimplement in configure --with-netlib
> >lapack=%{buildroot}%{_libdir}/liblapack_pic.a?
>
> All things are possible. I was trying to simplify my life by eliminating
> it, however. In particular, people tend to build lapack with incompatible
> flags, and then write in for help because ATLAS doesn't work. I therefore
> thought I'd simplify the framework by not having this option anymore, and
> also cut down the user help requests by always having ATLAS build it.

Maybe we can give both options. So everyone can choose, what he wants.
The Problem is, we have an own lapack Package in out Buildservice. I add all
relevant Packages to my chroot (buildroot). Then i can give configure the Path
to the needed Lib.
In the present status i must add an Tarfile from an Program, who exists
already an own Package.
Do you know what i mean?

--
Sincerely Yours

Sascha Manns
openSUSE Ambassador
openSUSE Build Service
openSUSE Marketing Team
Maifeldstrasse 10
D-56 727 Mayen

Phone: +49 2651 4014045
Fax: +49 3222 1764729
Email: saigkill@...
Web: http://saschamanns.gulli.to
Project-Blog: http://lizards.opensuse.org/author/saigkill
Private-Blog: http://saschasbacktrace.blogspot.com

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Math-atlas-devel mailing list
Math-atlas-devel@...
https://lists.sourceforge.net/lists/listinfo/math-atlas-devel

Re: Reimplement lapack

2009-09-04T15:28:07Z

Guys,

>Can we reimplement in configure --with-netlib
>lapack=%{buildroot}%{_libdir}/liblapack_pic.a?

All things are possible. I was trying to simplify my life by eliminating it,
however. In particular, people tend to build lapack with incompatible flags,
and then write in for help because ATLAS doesn't work. I therefore thought I'd
simplify the framework by not having this option anymore, and also cut down the
user help requests by always having ATLAS build it.

Does anyone else really want this option? I suppose if enough knowledgable
people use it, I could add it back, and perhaps not mention it in the
docs . . .

I would have to scope things out, because there were some tricks I was pulling
that worked best if I built the source (not sure what they were anymore) . . .

?
Clint

**************************************************************************
** R. Clint Whaley, PhD ** Assist Prof, UTSA ** www.cs.utsa.edu/~whaley **
**************************************************************************

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Math-atlas-devel mailing list
Math-atlas-devel@...
https://lists.sourceforge.net/lists/listinfo/math-atlas-devel