|
Reimplement lapack
|
|
Re: Reimplement lapack
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
|
|
Re: Reimplement lapack
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.toProject-Blog: http://lizards.opensuse.org/author/saigkillPrivate-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
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
Some parts of this message have been removed.
Learn more about Nabble's security policy.
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
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.toBlog: 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
Some parts of this message have been removed.
Learn more about Nabble's security policy.
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.
------------------------------------------------------------------------------
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
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
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.toBlog: 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
Some parts of this message have been removed.
Learn more about Nabble's security policy.
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.
------------------------------------------------------------------------------
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
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
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.toBlog: 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
Some parts of this message have been removed.
Learn more about Nabble's security policy.
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
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
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
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.toBlog: http://saigkill.wordpress.comTwitter: http://twitter.com/saigkillClaimID: 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
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
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
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
|
