On Sun, 29 Sep 2013 23:57:21 +0200
Kevin Kofler kevin.kof...@chello.at wrote:
Susi Lehtola wrote:
On Sun, 29 Sep 2013 01:04:31 +0200
Kevin Kofler kevin.kof...@chello.at wrote:
Susi Lehtola wrote:
If you link to -lblas, you're shooting yourself in the leg in the first
place, since
On Mon, 30 Sep 2013 10:03:14 +0300
Susi Lehtola jussileht...@fedoraproject.org wrote:
On Sun, 29 Sep 2013 23:57:21 +0200
Kevin Kofler kevin.kof...@chello.at wrote:
Susi Lehtola wrote:
On Sun, 29 Sep 2013 01:04:31 +0200
Kevin Kofler kevin.kof...@chello.at wrote:
Susi Lehtola
Susi Lehtola wrote:
Yes, but everyone knows that if you want ATLAS, the link command is
-L%{_libdir} -llapack -lf77blas -latlas
Everyone knows? I think pretty much everyone expects to link their stuff
with -llapack -lblas and get the most efficient implementation out there,
especially when
Susi Lehtola wrote:
FPC maintains packaging guidelines. If you think that BLAS/LAPACK
packages should have their own guideline, then file a proposition to
the FPC. FESCO is still there if the matter needs to be escalated from
the FPC.
https://fedorahosted.org/fpc/ticket/352
Kevin
On Sun, 29 Sep 2013 01:04:31 +0200
Kevin Kofler kevin.kof...@chello.at wrote:
Susi Lehtola wrote:
If you link to -lblas, you're shooting yourself in the leg in the first
place, since that's the reference implementation on current Fedoras.
In fact, I noticed that, and that's a serious
On Sun, 29 Sep 2013 01:05:23 +0200
Kevin Kofler kevin.kof...@chello.at wrote:
Susi Lehtola wrote:
Again, you should file a bug to the FPC about this.
Is this really the FPC's responsibility? I'd expect this to be the
maintainer's, and for escalation FESCO's.
FPC maintains packaging
On Sun, 29 Sep 2013 11:25:27 +0300
Susi Lehtola jussileht...@fedoraproject.org wrote:
On Sun, 29 Sep 2013 01:05:23 +0200
Kevin Kofler kevin.kof...@chello.at wrote:
Susi Lehtola wrote:
Again, you should file a bug to the FPC about this.
Is this really the FPC's responsibility? I'd
Susi Lehtola wrote:
On Sun, 29 Sep 2013 01:04:31 +0200
Kevin Kofler kevin.kof...@chello.at wrote:
Susi Lehtola wrote:
If you link to -lblas, you're shooting yourself in the leg in the first
place, since that's the reference implementation on current Fedoras.
In fact, I noticed that, and
I wrote:
The existing ATLAS setup (before the change) just worked!
Actually, I just noticed the ATLAS packages we ship in F18 are also broken:
libblas.so.3 is missing, so if something links only -lblas, or links -lblas
before -llapack etc., it will get the unoptimized reference BLAS functions!
On Sat, 28 Sep 2013 12:59:13 +0200
Kevin Kofler kevin.kof...@chello.at wrote:
I wrote:
The existing ATLAS setup (before the change) just worked!
Actually, I just noticed the ATLAS packages we ship in F18 are also broken:
libblas.so.3 is missing, so if something links only -lblas, or links
On Sat, 28 Sep 2013 13:01:33 +0200
Kevin Kofler kevin.kof...@chello.at wrote:
Orion Poplawski wrote:
Upstream, upstream, upstream It's not like Fedora decided to change
these things.
We should indeed bring this to ATLAS upstream, opening a similar bug report
there as for OpenBLAS.
Susi Lehtola wrote:
If you link to -lblas, you're shooting yourself in the leg in the first
place, since that's the reference implementation on current Fedoras.
In fact, I noticed that, and that's a serious packaging bug.
If a package links -lblas -llapack, if ATLAS is installed, it'll get
Susi Lehtola wrote:
Again, you should file a bug to the FPC about this.
Is this really the FPC's responsibility? I'd expect this to be the
maintainer's, and for escalation FESCO's.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
On Thu, 26 Sep 2013 17:52:27 +0200
Kevin Kofler kevin.kof...@chello.at wrote:
I wrote:
FYI, the author of netlib-java filed an issue with OpenBLAS for that:
https://github.com/xianyi/OpenBLAS/issues/296
I'm going to reproduce here the comment that I posted there:
| The situation I'm
On Thu, 26 Sep 2013 17:52:27 +0200
Kevin Kofler kevin.kof...@chello.at wrote:
For the end users, it means that
| they can install the most optimized implementation we provide for their
| CPU, or even build their own (tuned for the exact properties of their
| machine), without having to
Susi Lehtola wrote:
Multicore CPUs are nowadays the norm, and packages should really use
libraries that support this approach. Thus your argument is obsolete.
The parallel libraries are not interchangeable.
I'd rather have an optimized serial implementation than being stuck with the
Susi Lehtola wrote:
On Thu, 26 Sep 2013 17:52:27 +0200
Kevin Kofler kevin.kof...@chello.at wrote:
For the end users, it means that
| they can install the most optimized implementation we provide for their
| CPU, or even build their own (tuned for the exact properties of their
| machine),
Frantisek Kluknavsky wrote:
Atlas in rawhide is rebased to 3.10.1. It now builds monolithic shared
libraries libsatlas.so and libtatlas.so (serial and threaded, otherwise
identical) which include former lapack, blas and atlas libraries.
Dependent packages need to link -lsatlas or -ltatlas
On 9/27/2013 6:42 AM, Kevin Kofler wrote:
and I have to say I agree with him. The change to ATLAS packaging discussed
in this thread is NOT acceptable and should be reverted immediately, and
OpenBLAS should also be packaged as libblas.so.3 and liblapack.so.3. Having
libraries which would be
On 09/25/2013 09:47 PM, Kevin Kofler wrote:
Frantisek Kluknavsky wrote:
People with interest in secondary architectures might oppose that.
Which architectures are the problem? OpenBLAS currently supports:
| 2. Supported Architecture
|
|X86 : Pentium3 Katmai
|
On Thu, 26 Sep 2013 09:19:13 +0200
Frantisek Kluknavsky fkluk...@redhat.com wrote:
On 09/25/2013 09:47 PM, Kevin Kofler wrote:
Frantisek Kluknavsky wrote:
People with interest in secondary architectures might oppose that.
Which architectures are the problem? OpenBLAS currently supports:
On 09/26/2013 05:33 AM, Kevin Kofler wrote:
Susi Lehtola wrote:
OpenBLAS, ATLAS, ACML and MKL only ship one monolitchic library, so this
is not really an option.
FYI, the author of netlib-java filed an issue with OpenBLAS for that:
https://github.com/xianyi/OpenBLAS/issues/296
Unfortunately,
On 09/26/2013 09:36 AM, Dan Horák wrote:
Missing support for s390/s390x is a problem for us (with my red hat
on). Is there no fallback implementation?
Does is OpenBLAS fail completely when CPU not listed above is found?
Because for Power7 and up anything written for Power 7 will work.
Dan Horák wrote:
Missing support for s390/s390x is a problem for us (with my red hat
on). Is there no fallback implementation?
Does is OpenBLAS fail completely when CPU not listed above is found?
Because for Power7 and up anything written for Power 7 will work.
Unfortunately, from what I
Frantisek Kluknavsky wrote:
https://sourceforge.net/p/math-atlas/mailman/message/28515215/
So this was back in 2011 (!), why is that change hitting Fedora now?
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
I wrote:
FYI, the author of netlib-java filed an issue with OpenBLAS for that:
https://github.com/xianyi/OpenBLAS/issues/296
I'm going to reproduce here the comment that I posted there:
| Well, I'm also a Fedora packager, and I think that, as long as we want to
| support multiple
Frantisek Kluknavsky wrote:
People with interest in secondary architectures might oppose that.
Which architectures are the problem? OpenBLAS currently supports:
| 2. Supported Architecture
|
|X86 : Pentium3 Katmai
|Coppermine
| Athlon (not well optimized,
Susi Lehtola wrote:
OpenBLAS, ATLAS, ACML and MKL only ship one monolitchic library, so this
is not really an option.
FYI, the author of netlib-java filed an issue with OpenBLAS for that:
https://github.com/xianyi/OpenBLAS/issues/296
Unfortunately, upstream is reluctant to change this because
On Mon, Sep 23, 2013 at 2:12 PM, Orion Poplawski or...@cora.nwra.com wrote:
All of my atlas using packages are segfaulting on arm. I added a %check
section to the atlas package to run the atlas sanity checks and they are
segfaulting on arm as well. New build running here:
On 09/24/2013 09:38 AM, Jerry James wrote:
On Mon, Sep 23, 2013 at 2:12 PM, Orion Poplawski or...@cora.nwra.com wrote:
All of my atlas using packages are segfaulting on arm. I added a %check
section to the atlas package to run the atlas sanity checks and they are
segfaulting on arm as well.
Susi Lehtola wrote:
... huh?
ATLAS, OpenBLAS and (netlib reference) LAPACK are all mutually
incompatible packages.
If you linked with -L%{_libdir}/atlas -llapack -lf77blas -latlas, what
you ended up with is the ATLAS version (*not* the same as netlib
lapack!) of LAPACK and the ATLAS blas
Matthew Miller wrote:
Actually, what ATLAS upstream intends is for the program to be recompiled
on every installation (or boot, even). I think we used to have packages
that did that; this is a compromise.
Yes, ATLAS upstream has always been smoking deep crack. It looks like
OpenBLAS is the
On Mon, 23 Sep 2013 14:20:03 +0200
Kevin Kofler kevin.kof...@chello.at wrote:
Susi Lehtola wrote:
... huh?
ATLAS, OpenBLAS and (netlib reference) LAPACK are all mutually
incompatible packages.
If you linked with -L%{_libdir}/atlas -llapack -lf77blas -latlas,
what you ended up
On Mon, 23 Sep 2013 14:34:50 +0200
Kevin Kofler kevin.kof...@chello.at wrote:
Matthew Miller wrote:
Actually, what ATLAS upstream intends is for the program to be
recompiled on every installation (or boot, even). I think we used
to have packages that did that; this is a compromise.
Yes,
On 09/23/2013 02:46 PM, Susi Lehtola wrote:
Well, it's not too hard to understand why ATLAS does things the way it
does. It's already in the acronym: Automatically Tuned Linear Algebra
Software. You generate a library that is optimal for your processor. In
comparison, GotoBLAS (OpenBLAS) has
Susi Lehtola wrote:
OpenBLAS, ATLAS, ACML and MKL only ship one monolitchic library, so this
is not really an option.
That sucks (and at least ATLAS used not to do that), though linker scripts
could easily point both libblas.so and liblapack.so to a single monolithic
library at compile/link
On 09/22/2013 05:33 AM, Orion Poplawski wrote:
Any guidelines or suggestions as to whether to link to the serial or
threaded library?
For some not yet known reason, threaded library built in koji does not
work (fails at pthread_create). My local mockbuild works without any
problem. Use
Susi Lehtola wrote:
I might mention that OpenBLAS (successor to GotoBLAS) is in Fedora,
which is often 2x faster than ATLAS. But, it's only available on ix86
and x86_64.
Looks like armv7 is now being worked on (started Sep 14):
https://groups.google.com/forum/#!topic/openblas-dev/_tY90FOlkbU
On Mon, 23 Sep 2013 15:26:16 +0200
Frantisek Kluknavsky fkluk...@redhat.com wrote:
On 09/22/2013 05:33 AM, Orion Poplawski wrote:
Any guidelines or suggestions as to whether to link to the serial or
threaded library?
For some not yet known reason, threaded library built in koji does
On 09/22/2013 09:32 PM, Susi Lehtola wrote:
I might mention that OpenBLAS (successor to GotoBLAS) is in Fedora,
which is often 2x faster than ATLAS. But, it's only available on ix86
and x86_64. It does have runtime CPU detection, though for the 20-odd
CPUs supported.
Could you please add
On 09/22/2013 09:27 PM, Richard W.M. Jones wrote:
G.
Please don't [to ATLAS upstream, not Susi] do this. It breaks all
sorts of scenarios, especially virtual machine migration or simply
moving hard disks from one physical machine to another.
Arrange your code so it chooses the best
On Mon, 23 Sep 2013 16:15:16 +0200
Frantisek Kluknavsky fkluk...@redhat.com wrote:
On 09/22/2013 09:32 PM, Susi Lehtola wrote:
I might mention that OpenBLAS (successor to GotoBLAS) is in Fedora,
which is often 2x faster than ATLAS. But, it's only available on
ix86 and x86_64. It does have
Frantisek Kluknavsky wrote:
Atlas aims for a relatively narrow set of use cases. No virtualization.
No migration. Just the best possible performance on one given machine.
Virtual machines are notoriously known for varying performance. One can
not tune without exact benchmarking.
Of course,
On 09/23/2013 08:15 AM, Frantisek Kluknavsky wrote:
For the record: atlas-3.10.1-1.fc21.armv7hl.rpm is available. I do not have
any Arm machine to test except the Fedora builders, any feedback is welcome.
All of my atlas using packages are segfaulting on arm. I added a %check
section to the
On 09/23/2013 08:46 AM, Susi Lehtola wrote:
On Mon, 23 Sep 2013 14:34:50 +0200
Kevin Kofler kevin.kof...@chello.at wrote:
Matthew Miller wrote:
Actually, what ATLAS upstream intends is for the program to be
recompiled on every installation (or boot, even). I think we used
to have packages that
On 09/23/2013 08:02 PM, Kevin Kofler wrote:
Of course, this means that it is a very poor choice for our de-facto default
LAPACK/BLAS. (Only the reference implementation is worse. Yet, we build some
stuff even against that!)
I'd suggest filing a Change to make OpenBLAS the default for F21 (when
On Sat, 21 Sep 2013 19:22:11 -0600
Jerry James loganje...@gmail.com wrote:
On Sat, Sep 21, 2013 at 2:13 PM, Frantisek Kluknavsky
fkluk...@redhat.com wrote:
Hi,
Atlas in rawhide is rebased to 3.10.1. It now builds monolithic
shared libraries libsatlas.so and libtatlas.so (serial and
On Sun, Sep 22, 2013 at 10:05:12PM +0300, Susi Lehtola wrote:
On Sat, 21 Sep 2013 19:22:11 -0600
Jerry James loganje...@gmail.com wrote:
On Sat, Sep 21, 2013 at 2:13 PM, Frantisek Kluknavsky
fkluk...@redhat.com wrote:
Hi,
Atlas in rawhide is rebased to 3.10.1. It now builds
On Sun, 22 Sep 2013 20:27:52 +0100
Richard W.M. Jones rjo...@redhat.com wrote:
However, ATLAS still has different flavors for different CPUs (e.g.
3dnow, sse, sse2, sse3 etc). I'm not sure if this can be easily
handled with alternatives.
G.
Please don't [to ATLAS upstream, not
Susi Lehtola wrote:
I might mention that OpenBLAS (successor to GotoBLAS) is in Fedora,
which is often 2x faster than ATLAS. But, it's only available on ix86
and x86_64. It does have runtime CPU detection, though for the 20-odd
CPUs supported.
That's great, but if programs are now going to
On Sun, 22 Sep 2013 23:42:05 +0200
Kevin Kofler kevin.kof...@chello.at wrote:
Susi Lehtola wrote:
I might mention that OpenBLAS (successor to GotoBLAS) is in Fedora,
which is often 2x faster than ATLAS. But, it's only available on
ix86 and x86_64. It does have runtime CPU detection, though
On Sun, Sep 22, 2013 at 08:27:52PM +0100, Richard W.M. Jones wrote:
However, ATLAS still has different flavors for different CPUs (e.g.
3dnow, sse, sse2, sse3 etc). I'm not sure if this can be easily handled
with alternatives.
Please don't [to ATLAS upstream, not Susi] do this. It breaks
Hi,
Atlas in rawhide is rebased to 3.10.1. It now builds monolithic shared
libraries libsatlas.so and libtatlas.so (serial and threaded, otherwise
identical) which include former lapack, blas and atlas libraries.
Dependent packages need to link -lsatlas or -ltatlas instead of -latlas
-lcblas
On Sat, Sep 21, 2013 at 2:13 PM, Frantisek Kluknavsky
fkluk...@redhat.com wrote:
Hi,
Atlas in rawhide is rebased to 3.10.1. It now builds monolithic shared
libraries libsatlas.so and libtatlas.so (serial and threaded, otherwise
identical) which include former lapack, blas and atlas libraries.
On 09/21/2013 02:13 PM, Frantisek Kluknavsky wrote:
Hi,
Atlas in rawhide is rebased to 3.10.1. It now builds monolithic shared
libraries libsatlas.so and libtatlas.so (serial and threaded, otherwise
identical) which include former lapack, blas and atlas libraries.
Dependent packages need to
55 matches
Mail list logo
