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
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 whe
On Mon, 30 Sep 2013 10:03:14 +0300
Susi Lehtola wrote:
> On Sun, 29 Sep 2013 23:57:21 +0200
> Kevin Kofler wrote:
>
> > Susi Lehtola wrote:
> >
> > > On Sun, 29 Sep 2013 01:04:31 +0200
> > > Kevin Kofler wrote:
> > >> Susi Lehtola wrote:
> > >> > If you link to -lblas, you're shooting yourself
On Sun, 29 Sep 2013 23:57:21 +0200
Kevin Kofler wrote:
> Susi Lehtola wrote:
>
> > On Sun, 29 Sep 2013 01:04:31 +0200
> > Kevin Kofler 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 implemen
Susi Lehtola wrote:
> On Sun, 29 Sep 2013 01:04:31 +0200
> Kevin Kofler 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
On Sun, 29 Sep 2013 11:25:27 +0300
Susi Lehtola wrote:
> On Sun, 29 Sep 2013 01:05:23 +0200
> Kevin Kofler 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 f
On Sun, 29 Sep 2013 01:05:23 +0200
Kevin Kofler 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 guidelines. If you thin
On Sun, 29 Sep 2013 01:04:31 +0200
Kevin Kofler 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 packaging bug.
>
> I
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
https://admin.fedoraproject.org/mailma
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
r
On Sat, 28 Sep 2013 13:01:33 +0200
Kevin Kofler 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. However, I thin
On Sat, 28 Sep 2013 12:59:13 +0200
Kevin Kofler 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 -lblas
> before
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. However, I think we should not wait for upstream to
fix this horribly broken setup.
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 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 binar
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 i
Susi Lehtola wrote:
> On Thu, 26 Sep 2013 17:52:27 +0200
> Kevin Kofler 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
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
unoptim
On Thu, 26 Sep 2013 17:52:27 +0200
Kevin Kofler 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 recompile all the packages
On Thu, 26 Sep 2013 17:52:27 +0200
Kevin Kofler 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 thinking of is an
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 implementati
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
Fedor
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 wha
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.
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 Thu, 26 Sep 2013 09:19:13 +0200
Frantisek Kluknavsky 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:
> > | 2. S
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
|Coppermine
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
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, thou
On 09/24/2013 09:38 AM, Jerry James wrote:
On Mon, Sep 23, 2013 at 2:12 PM, Orion Poplawski 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 her
On Mon, Sep 23, 2013 at 2:12 PM, Orion Poplawski 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:
>
> http://koji.fedoraproject.org/koj
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 09/23/2013 08:46 AM, Susi Lehtola wrote:
On Mon, 23 Sep 2013 14:34:50 +0200
Kevin Kofler 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 co
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 a
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 Mon, 23 Sep 2013 16:15:16 +0200
Frantisek Kluknavsky 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 runtime CP
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 availa
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 more
On Mon, 23 Sep 2013 15:26:16 +0200
Frantisek Kluknavsky 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
> 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.
Looks like armv7 is now being worked on (started Sep 14):
https://groups.google.com/forum/#!topic/openblas-dev/_tY90FOlkbU
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 ser
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/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 been
On Mon, 23 Sep 2013 14:34:50 +0200
Kevin Kofler 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, ATLAS upstream
On Mon, 23 Sep 2013 14:20:03 +0200
Kevin Kofler 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 with is the
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
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 ATL
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 br
On Sun, 22 Sep 2013 23:42:05 +0200
Kevin Kofler 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 for the
> > 20-o
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 20:27:52 +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.
>
> G.
>
> Please don't [to ATLAS upstream, not Susi] do t
On Sun, Sep 22, 2013 at 10:05:12PM +0300, Susi Lehtola wrote:
> On Sat, 21 Sep 2013 19:22:11 -0600
> Jerry James wrote:
>
> > On Sat, Sep 21, 2013 at 2:13 PM, Frantisek Kluknavsky
> > wrote:
> > > Hi,
> > >
> > > Atlas in rawhide is rebased to 3.10.1. It now builds monolithic
> > > shared librar
On Sat, 21 Sep 2013 19:22:11 -0600
Jerry James wrote:
> On Sat, Sep 21, 2013 at 2: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)
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 link
On Sat, Sep 21, 2013 at 2: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
> pa
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
56 matches
Mail list logo