Re: Is it possible atlas is linked wrongly by new binutils?

[Susi Lehtola]

On 08/15/2017 02:47 PM, Kevin Kofler wrote:

Please note that what I am proposing here is not the same as my proposal
from 3 years ago that was rejected. While I would not complain if my old
proposal were implemented, I am now suggesting a much simpler approach
(which was already hinted at in the last paragraph of my old proposal):

* drop the inefficient implementations reference (netlib) BLAS/LAPACK and
ATLAS (have OpenBLAS Obsolete them),


Why?


* use one-way symlinks or linker scripts to make everything linking or
linked to them pick up OpenBLAS instead. So libblas, liblapack and libsatlas
would just redirect to libopenblas,


This could be easier done just by linking to -lopenblas.


* I am not sure about libtatlas, ideally it should redirect to libopenblaso,
but libtatlas uses raw pthread wheres libopenblaso uses OpenMP, this may
make a difference (e.g., it will certainly cause problems if the client
program uses OpenMP itself). If libopenblaso does not work as a drop-in
libtatlas replacement, libopenblas would have to be used instead (and the
programs that really want libopenblaso would have to be rebuilt for it).


Actually, the problem is a bit bigger. The basic OpenBLAS library comes 
in three variants:

- sequential (libopenblas)
- pthreads (libopenblasp)
- OpenMP (libopenblaso)

The problem is that you can't mix these. Now, I use a lot of BLAS/LAPACK 
and sometimes even within OpenMP parallel regions. The only library I 
would use is libopenblaso, because by doing so you get parallel 
performance in sequential regions, but it doesn't parallellize when you 
call a routine within a parallel region (otherwise you'll launch too 
many threads and destroy your performance).


While the OpenMP version has a marginally larger overhead than the 
pthreads one, it is the OpenMP version that should be default.


However, in addition to these three main flavors, the library *also* 
comes in versions that support 64-bit indexing (the good old 4-byte vs 
8-byte Fortran integer problem):

- libopenblas{,p,o} is the 32-bit integer one
- libopenblas{,p,o}64 is the 64-bit integer one - which has the same
  symbol names as libopenblas{,p,o} !!
- libopenblas{,p,o}64_ is the 64-bit integer one with a _ suffix so you
  can link the same application to the 32-bit version libopenblas{,p,o}

so it's not a simple question of libblas.so and liblapack.so
--
Susi Lehtola
Fedora Project Contributor
jussileht...@fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Is it possible atlas is linked wrongly by new binutils?

[Susi Lehtola]

On 08/14/2017 03:35 AM, Kevin Kofler wrote:

That said, ATLAS should really go away, unless they add support for runtime
CPU detection and the result matches or exceeds OpenBLAS performance. In its
current state (which has been the state since its inception), ATLAS is
really unsuitable for distribution packaging. They just do not care about
binary packages, at all.


This is kind of like saying vim should go away, because emacs is better.


It is the job of the distribution to ensure that software uses the most
efficient BLAS/LAPACK implementation available. Other distributions ship
symlinks ensuring that. The current packaging in Fedora is horrible.


"Other distributions" typically end up using reference BLAS/LAPACK due 
to the horrible symlink/alternatives system, and/or end up with broken 
implementations.


I'm sure a better way to do things would be possible, it's just hard to 
imagine a perfect system.

--
Susi Lehtola
Fedora Project Contributor
jussileht...@fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

OpenBLAS as the default BLAS (was: Re: Is it possible atlas is linked wrongly by new binutils?)

[Dominik 'Rathann' Mierzejewski]

On Saturday, 12 August 2017 at 00:11, Dominik 'Rathann' Mierzejewski wrote:
> On Thursday, 10 August 2017 at 12:29, Richard W.M. Jones wrote:
> > Never mind.  Something in the atlas build segfaults when building
> > on ppc64le:
> > 
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=21145734
> > 
> > This is a mess :-(
> 
> Just switch to openblas already. ;)
> 
> I'd propose a Change for F28 to switch to openblas
> as the default implementation if I had some help.
> Any volunteers?

I've just started:
https://fedoraproject.org/wiki/Changes/OpenBLAS_as_default_BLAS
It looks like only 34 packages are affected. Help is welcome.

We probably also need to add something to the Packaging Guidelines
to ensure new packages use OpenBLAS by default.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPMFusion   http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Is it possible atlas is linked wrongly by new binutils?

[Richard W.M. Jones]

On Fri, Aug 18, 2017 at 08:04:52AM +0200, Jakub Martisko wrote:
> It should work now [1].
> 
> Jakub
> 
> [1]:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=21296324

Thanks, I'll try to rebuild ocaml-gsl & ocaml-lacaml shortly.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Is it possible atlas is linked wrongly by new binutils?

[Jakub Martisko]

It should work now [1].

Jakub

[1]:
https://koji.fedoraproject.org/koji/taskinfo?taskID=21296324

On 9.8.2017 11:37, Richard W.M. Jones wrote:
> 
> ocaml-gsl (OCaml bindings for GNU Scientific Library) currently
> fails to link to atlas:
> 
> + /usr/bin/ocamlfind ocamlopt -g -I lib -linkpkg -package bigarray -I lib -I 
> examples lib/gsl.cmxa examples/blas_ex.cmx -o examples/blas_ex.native
> /usr/lib64/atlas/libsatlas.so: undefined reference to `dlarfy_'
> /usr/lib64/atlas/libsatlas.so: undefined reference to `slarfy_'
> /usr/lib64/atlas/libsatlas.so: undefined reference to `clarfy_'
> /usr/lib64/atlas/libsatlas.so: undefined reference to `zlarfy_'
> collect2: error: ld returned 1 exit status
> 
> However this only happens with the very latest atlas that was built by
> binutils 2.29 (atlas-3.10.2-18.fc27.x86_64).  It doesn't occur with
> the previous version of atlas (atlas-3.10.2-16.fc26) even though there
> seems to have been no change in atlas.
> 
> $ nm -D /usr/lib64/atlas/libtatlas.so | grep larfy
>  U clarfy_
>  U dlarfy_
>  U slarfy_
>  U zlarfy_
> 
> I looked in /usr/lib64 on my development machine which has atlas
> installed but there is no .so* file that I can find which defines
> these symbols.  I also couldn't work out where in the atlas code
> (which is a bit strange) these references are used.
> 
> Hence the question: Is this breakage in atlas?  binutils?
> 
> Rich.
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Is it possible atlas is linked wrongly by new binutils?

[Benson Muite]

On 08/17/2017 12:05 AM, Dan Horák wrote:

On Wed, 16 Aug 2017 22:57:28 +0200
Kevin Kofler  wrote:


Dave Love wrote:


Kevin Kofler writes:

If you are talking about the missing RPM AutoProvides:
Provides: libblas.so.3()(64bit)
does wonders.


I mean you need to get the soname right and ensure that you have
everything implemented in the replacement library.


Only the soname of the Provides matters. The actual library file can
be a symlink to the monolithic libopenblas.so.0, the dynamic linker
(ld.so) will load it just fine. The soname is only read at link time,
and there, it is fine (and in fact desired) that newly linked
applications get libopenblas.so.0 recorded as the soname, not
libblas.so.3.


Various things have been changed to use openblas on x86 after
some of us agitated.


The problem is, "various things" is not enough, we need a plan to
ensure ALL things use it.


It's not available for them all as far as I know -- there's an rpm
macro which says which ones.  I'm happy if that's wrong now.


"things" = "packages" here. Surely OpenBLAS should work for all the
BLAS- using packages on x86, especially if we symlink libblas.so to
it. If not, it is a bug either in OpenBLAS or in the package.

OpenBLAS is not available for some exotic architectures, but the
solution there is to build ATLAS (or some other implementation) for
those architectures (and those architectures only) and set up the
symlinks there too.


in F-27+ we should have OpenBLAS available for all active Fedora
architectures


Dan
___

OpenBLAS (https://github.com/xianyi/OpenBLAS) and BLIS 
(https://github.com/flame/blis) are nice, but for performance, may need 
to rethink packaging entirely. Ability to use GPUs may require better 
coordination with upstream developers - clBLAS looks promising for this, 
but seemed not to have gained much traction. This would be particularly 
useful for single precision applications such as image and audio 
processing. RocBLAS (https://github.com/ROCmSoftwarePlatform/rocBLAS) is 
an open alternative, but mostly for AMD. For commonly used libraries, 
might it be worth getting performance information in Koji or Copr? It 
may also be good to allow intelligent performance based choice of BLAS 
library based on architecture, what may be the best library on a 2 core 
mobile platform, 32 core workstation, ARM cloud server, Power cloud 
server etc. may be quite different.


Having a correct and slow reference BLAS is also useful. Though 
expectation of average user to choose correct BLAS implementation may be 
too much - packager may have a better idea of a reasonable default.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Is it possible atlas is linked wrongly by new binutils?

[Tom Callaway]

On 08/16/2017 04:34 PM, Tom Callaway wrote:
> 
> 
> On 08/09/2017 05:37 AM, Richard W.M. Jones wrote:
>>
>> ocaml-gsl (OCaml bindings for GNU Scientific Library) currently
>> fails to link to atlas:
>>
>> + /usr/bin/ocamlfind ocamlopt -g -I lib -linkpkg -package bigarray -I lib -I 
>> examples lib/gsl.cmxa examples/blas_ex.cmx -o examples/blas_ex.native
>> /usr/lib64/atlas/libsatlas.so: undefined reference to `dlarfy_'
>> /usr/lib64/atlas/libsatlas.so: undefined reference to `slarfy_'
>> /usr/lib64/atlas/libsatlas.so: undefined reference to `clarfy_'
>> /usr/lib64/atlas/libsatlas.so: undefined reference to `zlarfy_'
> 
> This is because I bumped lapack in rawhide. Atlas uses liblapack.a, and
> the first lapack 3.7.1 builds were missing some symbols. Everything is
> fixed now in lapack in rawhide, but I forgot atlas was doing this. I
> have an atlas rebuild going now that should resolve the error.

Or, it would, if it wasn't failing on s390x. I miss secondary architectures.

https://koji.fedoraproject.org/koji/taskinfo?taskID=21267770

~tom
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Is it possible atlas is linked wrongly by new binutils?

[Dan Horák]

On Wed, 16 Aug 2017 22:57:28 +0200
Kevin Kofler  wrote:

> Dave Love wrote:
> 
> > Kevin Kofler writes:
> >> If you are talking about the missing RPM AutoProvides:
> >> Provides: libblas.so.3()(64bit)
> >> does wonders.
> > 
> > I mean you need to get the soname right and ensure that you have
> > everything implemented in the replacement library.
> 
> Only the soname of the Provides matters. The actual library file can
> be a symlink to the monolithic libopenblas.so.0, the dynamic linker
> (ld.so) will load it just fine. The soname is only read at link time,
> and there, it is fine (and in fact desired) that newly linked
> applications get libopenblas.so.0 recorded as the soname, not
> libblas.so.3.
> 
> >>> Various things have been changed to use openblas on x86 after
> >>> some of us agitated.
> >>
> >> The problem is, "various things" is not enough, we need a plan to
> >> ensure ALL things use it.
> > 
> > It's not available for them all as far as I know -- there's an rpm
> > macro which says which ones.  I'm happy if that's wrong now.
> 
> "things" = "packages" here. Surely OpenBLAS should work for all the
> BLAS- using packages on x86, especially if we symlink libblas.so to
> it. If not, it is a bug either in OpenBLAS or in the package.
> 
> OpenBLAS is not available for some exotic architectures, but the
> solution there is to build ATLAS (or some other implementation) for
> those architectures (and those architectures only) and set up the
> symlinks there too.

in F-27+ we should have OpenBLAS available for all active Fedora
architectures


Dan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Is it possible atlas is linked wrongly by new binutils?

[Kevin Kofler]

Dave Love wrote:

> Kevin Kofler writes:
>> If you are talking about the missing RPM AutoProvides:
>> Provides: libblas.so.3()(64bit)
>> does wonders.
> 
> I mean you need to get the soname right and ensure that you have
> everything implemented in the replacement library.

Only the soname of the Provides matters. The actual library file can be a 
symlink to the monolithic libopenblas.so.0, the dynamic linker (ld.so) will 
load it just fine. The soname is only read at link time, and there, it is 
fine (and in fact desired) that newly linked applications get 
libopenblas.so.0 recorded as the soname, not libblas.so.3.

>>> Various things have been changed to use openblas on x86 after some of us
>>> agitated.
>>
>> The problem is, "various things" is not enough, we need a plan to ensure
>> ALL things use it.
> 
> It's not available for them all as far as I know -- there's an rpm macro
> which says which ones.  I'm happy if that's wrong now.

"things" = "packages" here. Surely OpenBLAS should work for all the BLAS-
using packages on x86, especially if we symlink libblas.so to it. If not, it 
is a bug either in OpenBLAS or in the package.

OpenBLAS is not available for some exotic architectures, but the solution 
there is to build ATLAS (or some other implementation) for those 
architectures (and those architectures only) and set up the symlinks there 
too.

>> But the new approach I am proposing installs only one version of both
>> BLAS and LAPACK (the OpenBLAS one), so there cannot possibly be
>> mismatched versions (except if you have third-party binaries bundling
>> BLAS and linking to the system LAPACK or the other way round, but those
>> are then very broken and will also fail on other distributions for the
>> same reason).
> 
> "Third party" (user and system) binaries linking non-OB linear algebra
> is normal on the sort of systems I work on, though I wish I was allowed
> to package system installations.  (Red Hat would have caused chaos on
> our systems by introducing backwards-incompatible openmpi if it hadn't
> been caught by the local package dependencies.)

It is fine if third-party binaries either:
* link to the system version of both BLAS and LAPACK, or
* bundle their own version of both BLAS and LAPACK.

The only case where you can end up with an incompatible mix is if they link 
to the system version of one and bundle the other, which is very broken and 
hopefully not too common. (It will also break on Debian.)

> Also, OB still has at least some correctness problems as far as I know,
> e.g. .

According to the comments, the latest version has precision issues only in 
the single-precision version. If you are using single precision where 
precision matters, you have a problem already.

Also, having an error of 17.something times a small error instead of 16.00 
times is hardly "incorrect". I would be more worried if it were returning 
completely wrong results (e.g., 1 instead of 0 or something like that).

And in the end, all software has bugs. glibc also has bugs, so should we 
attempt to make all of Fedora switchable to musl at runtime (or worse, 
arbitrarily link some of it to glibc, some to musl, some to ucLibc, and some 
to dietlibc, just because we can – this is the situation with BLAS/LAPACK 
right now)?

And keep in mind that floating-point computation ALWAYS returns 
approximations. If you need rigorous error bounds, you probably need 
something completely different entirely (e.g., interval arithmetic), which 
will of course have its own limitations.

> Is there actually anything wrong with Debian's tried and tested approach
> as long as openblas is preferred where appropriate?

Sorry, I really don't like the alternatives system. It requires you to make 
a global systemwide switch to change your implementation. If you want to 
make the implementation switchable by the user, it needs to be a runtime 
choice (using, e.g., environment modules). But I think we do not have to 
leave this decision to the user to begin with.

>> ld.so.conf.d is the only way to build those [versions optimized for
>> subarchitectures where no runtime detection is available], if you want to
>> support them. I wonder whether non-x86 architectures are even worth
>> investing the effort.
> 
> How would relevant hwcaps not help, if they were available, as they
> seemed to be on some architectures when I looked some time ago?  (That
> used to be important on SPARC for efficiency in crypto libraries, at
> least.)

My point is, those architectures are so rarely used, with Fedora at least, 
that I wonder whether it is worth Fedora maintainers' time to optimize for 
their subarchitectures. Of course it will give a performance benefit, that 
goes without doubt. But is it worth our time considering the actual usage?

> Yes it is, but if you can have atlas-sse3, I don't see why you can't
> have blis-avx512.  (Dynamism was on the radar for BLIS when I last
> looked, and might be 

Re: Is it possible atlas is linked wrongly by new binutils?

[Tom Callaway]

On 08/09/2017 05:37 AM, Richard W.M. Jones wrote:
> 
> ocaml-gsl (OCaml bindings for GNU Scientific Library) currently
> fails to link to atlas:
> 
> + /usr/bin/ocamlfind ocamlopt -g -I lib -linkpkg -package bigarray -I lib -I 
> examples lib/gsl.cmxa examples/blas_ex.cmx -o examples/blas_ex.native
> /usr/lib64/atlas/libsatlas.so: undefined reference to `dlarfy_'
> /usr/lib64/atlas/libsatlas.so: undefined reference to `slarfy_'
> /usr/lib64/atlas/libsatlas.so: undefined reference to `clarfy_'
> /usr/lib64/atlas/libsatlas.so: undefined reference to `zlarfy_'

This is because I bumped lapack in rawhide. Atlas uses liblapack.a, and
the first lapack 3.7.1 builds were missing some symbols. Everything is
fixed now in lapack in rawhide, but I forgot atlas was doing this. I
have an atlas rebuild going now that should resolve the error.

~tom
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Is it possible atlas is linked wrongly by new binutils?

[Dave Love]

Kevin Kofler  writes:

> Dave Love wrote:
>> You'll find Dominik was correct if you try it.
>
> If you are talking about the missing RPM AutoProvides:
> Provides: libblas.so.3()(64bit)
> does wonders.

I mean you need to get the soname right and ensure that you have
everything implemented in the replacement library.

>> Various things have been changed to use openblas on x86 after some of us
>> agitated.
>
> The problem is, "various things" is not enough, we need a plan to ensure ALL 
> things use it.

It's not available for them all as far as I know -- there's an rpm macro
which says which ones.  I'm happy if that's wrong now.

>> As far as I remember, there's good reason (apart from the previous
>> (FPC?) vote against it), like the atlas blas and lapack have to go
>> together.
>
> If the ld.so.conf.d override were implemented correctly, it would just work. 

Yes, with caveats above.  (My hack just worked for at least a couple of
years on a general-purpose HPC system.)

> The issue with the old state was that there was only an override for 
> liblapack installed and not for libblas, which is of course very broken.
>
> But the new approach I am proposing installs only one version of both BLAS 
> and LAPACK (the OpenBLAS one), so there cannot possibly be mismatched 
> versions (except if you have third-party binaries bundling BLAS and linking 
> to the system LAPACK or the other way round, but those are then very broken 
> and will also fail on other distributions for the same reason).

"Third party" (user and system) binaries linking non-OB linear algebra
is normal on the sort of systems I work on, though I wish I was allowed
to package system installations.  (Red Hat would have caused chaos on
our systems by introducing backwards-incompatible openmpi if it hadn't
been caught by the local package dependencies.)

Also, OB still has at least some correctness problems as far as I know,
e.g. .

Is there actually anything wrong with Debian's tried and tested approach
as long as openblas is preferred where appropriate?

>> It will exceed it on any relevant platform that openblas doesn't
>> support,
>
> Is there even such a platform, the keyword being "relevant"? :-)

Apparently, as above.

>> but where OB doesn't do DYNAMIC_ARCH you still have the problem of needing
>> micro-architecture-specific packages (which seems to be against policy,
>> although atlas does it).
>
> ld.so.conf.d is the only way to build those, if you want to support them. I 
> wonder whether non-x86 architectures are even worth investing the effort.

How would relevant hwcaps not help, if they were available, as they
seemed to be on some architectures when I looked some time ago?  (That
used to be important on SPARC for efficiency in crypto libraries, at least.)
>> On avx512, that's BLIS (+libxsmm), but MKL is still substantially faster.
>
> Well, another technical criterion is that we can really only pick the 
> default implementation per architecture (e.g., x86_64), not per 
> subarchitecture (e.g., AVX-512), and I think OpenBLAS is still the best 
> option for x86_64 overall (also because it supports runtime subarchitecture 
> detection and BLIS does not).

Yes it is, but if you can have atlas-sse3, I don't see why you can't
have blis-avx512.  (Dynamism was on the radar for BLIS when I last
looked, and might be worth contributing, but I haven't evaluated it
against OB on anything other than KNL.)

> For AVX-512, I think what we really want is to get AVX-512 optimizations 
> into OpenBLAS. It can match MKL performance when it is using the same 
> instruction set,

I don't think that is generally true, even for avx < 512, but for the
major operations -- at least dgemm -- it equals or betters MKL for all
x86 I've tried from 10-year-old Opteron through to avx2.  (I think MKL
has more operations optimized.)

> see e.g. the graph for Sandy Bridge (AVX):
> https://github.com/xianyi/OpenBLAS/wiki/faq#sandybridge_perf
> Of course, if your CPU supports AVX-512 and your BLAS is only using AVX2 (as 
> OpenBLAS currently does), it will not be optimal, no surprise there.

I know how it performs, as above and in the link I posted for something
more recent than SB, but no-one is working on avx512 support as far as I
can tell, and the KNL qua Haswell is contributed is worse than you might
expect .

In case I seem to be arguing against it, let me stress that I think this
needs sanitizing, OB should be the default BLAS on the appropriate
platforms (all, if that works), and someone should be funded to add
KNL/Skylake support to OB.

Is it even possible to revisit this in view of the previous proposal
being rejected?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Is it possible atlas is linked wrongly by new binutils?

[Kevin Kofler]

Dave Love wrote:
> You'll find Dominik was correct if you try it.

If you are talking about the missing RPM AutoProvides:
Provides: libblas.so.3()(64bit)
does wonders.

> Various things have been changed to use openblas on x86 after some of us
> agitated.

The problem is, "various things" is not enough, we need a plan to ensure ALL 
things use it.

> As far as I remember, there's good reason (apart from the previous
> (FPC?) vote against it), like the atlas blas and lapack have to go
> together.

If the ld.so.conf.d override were implemented correctly, it would just work. 
The issue with the old state was that there was only an override for 
liblapack installed and not for libblas, which is of course very broken.

But the new approach I am proposing installs only one version of both BLAS 
and LAPACK (the OpenBLAS one), so there cannot possibly be mismatched 
versions (except if you have third-party binaries bundling BLAS and linking 
to the system LAPACK or the other way round, but those are then very broken 
and will also fail on other distributions for the same reason).

> It will exceed it on any relevant platform that openblas doesn't
> support,

Is there even such a platform, the keyword being "relevant"? :-)

OpenBLAS supports all these:
https://github.com/xianyi/OpenBLAS/blob/develop/GotoBLAS_01Readme.txt#L21
https://github.com/xianyi/OpenBLAS#additional-support-cpu

If you want anything else, sure, you can ExcludeArch OpenBLAS on them, build 
ATLAS as an ExclusiveArch package for them, and set up the symlinks 
accordingly. That should not be an obstacle to shipping an optimal 
implementation on our primary architectures. (Quite the opposite, it means 
that no other package would need %ifarch hacks, all the logic would stay 
confined to the OpenBLAS and ATLAS packages as it should be.)

> but where OB doesn't do DYNAMIC_ARCH you still have the problem of needing
> micro-architecture-specific packages (which seems to be against policy,
> although atlas does it).

ld.so.conf.d is the only way to build those, if you want to support them. I 
wonder whether non-x86 architectures are even worth investing the effort.

>> It is the job of the distribution to ensure that software uses the most
>> efficient BLAS/LAPACK implementation available. Other distributions ship
>> symlinks ensuring that. The current packaging in Fedora is horrible.
> 
> I presume that means the most efficient free implementation.

Sure, I mean the most efficient implementation available in Fedora, for 
which freeness is of course a prerequisite.

> On avx512, that's BLIS (+libxsmm), but MKL is still substantially faster.

Well, another technical criterion is that we can really only pick the 
default implementation per architecture (e.g., x86_64), not per 
subarchitecture (e.g., AVX-512), and I think OpenBLAS is still the best 
option for x86_64 overall (also because it supports runtime subarchitecture 
detection and BLIS does not).

For AVX-512, I think what we really want is to get AVX-512 optimizations 
into OpenBLAS. It can match MKL performance when it is using the same 
instruction set, see e.g. the graph for Sandy Bridge (AVX):
https://github.com/xianyi/OpenBLAS/wiki/faq#sandybridge_perf
Of course, if your CPU supports AVX-512 and your BLAS is only using AVX2 (as 
OpenBLAS currently does), it will not be optimal, no surprise there.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Is it possible atlas is linked wrongly by new binutils?

[Kevin Kofler]

(I am reversing the paragraphs so that the order of the replies makes 
sense.)

Dominik 'Rathann' Mierzejewski wrote:
> Thinking again, we had this discussion over 3 years ago:
> https://pagure.io/packaging-committee/issue/352
> and another one starting 2 years ago:
> https://pagure.io/packaging-committee/issue/588
> which is stalled because Orion doesn't have any time lately.

Please note that what I am proposing here is not the same as my proposal 
from 3 years ago that was rejected. While I would not complain if my old 
proposal were implemented, I am now suggesting a much simpler approach 
(which was already hinted at in the last paragraph of my old proposal):

* drop the inefficient implementations reference (netlib) BLAS/LAPACK and 
ATLAS (have OpenBLAS Obsolete them),

* use one-way symlinks or linker scripts to make everything linking or 
linked to them pick up OpenBLAS instead. So libblas, liblapack and libsatlas 
would just redirect to libopenblas,

* I am not sure about libtatlas, ideally it should redirect to libopenblaso, 
but libtatlas uses raw pthread wheres libopenblaso uses OpenMP, this may 
make a difference (e.g., it will certainly cause problems if the client 
program uses OpenMP itself). If libopenblaso does not work as a drop-in 
libtatlas replacement, libopenblas would have to be used instead (and the 
programs that really want libopenblaso would have to be rebuilt for it).

> On Monday, 14 August 2017 at 02:35, Kevin Kofler wrote:
>> Dominik 'Rathann' Mierzejewski wrote:
>> Symlinking
>> libblas.so.3 → libopenblas.so.0
>> liblapack.so.3 → libopenblas.so.0
>> is enough to get things linked against BLAS and/or LAPACK to pick up
>> OpenBLAS instead. A similar symlinking should work for the -devel
>> package. If the symlinks confuse ldconfig or cause some other issues,
>> linker scripts can be used instead.
> 
> It certainly won't be enough for RPM. There needs to be a libblas.so
> pointing to a library with SONAME libblas.so.3, same for lapack.

With the above proposal, if libblas.so symlinks to libopenblas.so.0, the 
built RPM will have an AutoRequires on libopenblas.so.0, which is fine 
(because that is what we want things to use).

For the runtime symlinks (e.g. libblas.so.3 → libopenblas.so.0), explicit 
Provides would be needed so that the dependencies in programs still 
depending on the legacy sonames can be resolved.


My old proposal, on the other hand, does not use symlinks to do the 
redirection at all, but ld.so.conf.d overrides. So that entirely bypasses 
the AutoRequires/AutoProvides system. In that proposal, the "libblas.so
pointing to a library with SONAME libblas.so.3" would come from the 
reference (netlib) BLAS's blas-devel package.

Hence, I do not understand your objection.


The old proposal is the way to go if you want to support multiple 
BLAS/LAPACK implementations. The new proposal is the way to go if you want 
to ship a BLAS/LAPACK that just works.

In any case, the goal ought to be that we centrally pick the BLAS/LAPACK 
implementation, either at runtime (old proposal) or at compile time (new 
proposal) instead of expecting each and every package using BLAS and/or 
LAPACK to be patched to pick up the preferred implementation, which is 
clearly not working. (We still have different packages linking to different 
implementations.)

This is really the same issue as what I complained about with the libidn2 
migration. It just does not scale to expect each and every package to be 
patched to change the name of the library to link, when the new library is a 
drop-in replacement API/ABI-wise and could just be shipped as a true drop-in 
replacement also picking up the old name. Doing the latter is not only much 
more efficient for the distribution, but also much less error-prone. Not 
only does it avoid inconsistencies (as we are seeing with BLAS/LAPACK) now, 
but, e.g., the pointless changes that were required for libidn2 ended up 
causing this fun bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1479146

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Is it possible atlas is linked wrongly by new binutils?

[Jakub Martisko]

On 15.8.2017 10:39, Dave Love wrote:

> 
> I don't know whether that's true, but Fedora could at least improve the
> situation by providing more than the -sse2 and -sse3 packages.
> 

I am planning to drop the sse2 sse3 subpackages and replace
them with something a bit more "modern" [1] with the rebase
to 3.10.3.

[1]: https://bugzilla.redhat.com/show_bug.cgi?id=1304402
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Is it possible atlas is linked wrongly by new binutils?

[Dave Love]

Kevin Kofler  writes:

> Dominik 'Rathann' Mierzejewski wrote:
>> It also needs some patching, because each library has a different
>> SONAME.
>
> Symlinking
> libblas.so.3 → libopenblas.so.0
> liblapack.so.3 → libopenblas.so.0
> is enough to get things linked against BLAS and/or LAPACK to pick up 
> OpenBLAS instead. A similar symlinking should work for the -devel package. 
> If the symlinks confuse ldconfig or cause some other issues, linker scripts 
> can be used instead.

You'll find Dominik was correct if you try it.

>> I think atlas used to provide a drop-in replacement, but it was abandoned
>
> Ouch! Indeed, the current ATLAS packages provide only libsatlas and 
> libtatlas, no libblas or liblapack. This is a regression and should never 
> have been packaged that way. Now all the packages end up with the 
> unoptimized reference BLAS.

Various things have been changed to use openblas on x86 after some of us
agitated.

> (In fact, I think I already noticed that when it 
> happened and complained loudly about it, but was ignored, as it seems. 
> Sigh!)

As far as I remember, there's good reason (apart from the previous
(FPC?) vote against it), like the atlas blas and lapack have to go
together.

> That said, ATLAS should really go away, unless they add support for runtime 
> CPU detection and the result matches or exceeds OpenBLAS performance.

It will exceed it on any relevant platform that openblas doesn't
support, but where OB doesn't do DYNAMIC_ARCH you still have the problem
of needing micro-architecture-specific packages (which seems to be
against policy, although atlas does it).

> In its 
> current state (which has been the state since its inception), ATLAS is 
> really unsuitable for distribution packaging. They just do not care about 
> binary packages, at all.

I don't know whether that's true, but Fedora could at least improve the
situation by providing more than the -sse2 and -sse3 packages.

>> on the premise that scientific codes are compiled specificlly for their
>> target clusters anyway
>
> … which is of course not true for distribution packages!

I might note that, typically, people who insist on specific compilation
haven't made relevant measurements -- I know that's not true generally
-- e.g. the myths about MKL et al.  Where reasonable, the computational
kernels that are sensitive to SIMD should be abstracted into libraries
like openblas, libxsmm, fftw, elpa, etc.

>> and Intel's math library (MKL) doesn't provide a drop-in replacement.
>
> … which is entirely irrelevant.
>
> It is the job of the distribution to ensure that software uses the most 
> efficient BLAS/LAPACK implementation available. Other distributions ship 
> symlinks ensuring that. The current packaging in Fedora is horrible.

I presume that means the most efficient free implementation.  On avx512,
that's BLIS (+libxsmm), but MKL is still substantially faster.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Is it possible atlas is linked wrongly by new binutils?

[Dave Love]

Matthew Miller  writes:

> On Sun, Aug 13, 2017 at 11:01:04AM +0200, Kevin Kofler wrote:
>> Can't we make it a drop-in replacement for reference BLAS/LAPACK and ATLAS, 
>> i.e., having symlinks or linker scripts pointing at least libblas.so and 
>> liblapack.so to libopenblas.so.*, ideally also libblas.so.3 and 
>> liblapack.so.3 so that no rebuilds are necessary and so that things using 
>> dlopen and third-party binary blobs also use OpenBLAS?
>> 
>> The current situation where we have 3 different BLAS implementations and 
>> where for most programs, depending on your setup, you get either the worst 
>> one (reference BLAS) or a suboptimal one (ATLAS compiled for the baseline 
>> architecture), but never the best one (OpenBLAS with runtime CPU detection), 
>> is a mess.
>
> This sounds like a good idea (and worthy of a Change). I hate to
> suggest Alternatives but maybe it's appropriate here? 

The sane Debian approach was rejected in committee previously.

There's some discussion and a technique for subverting the non-optimal
BLAS/LAPACK at .
[I actually only care about EPEL, and presumably RHEL's treatment of
linear algebra won't change.]

To support libraries which don't dispatch on the micro-architecture
(like BLIS, currently) it would be useful if SIMD hardware capabilities
were supported.  I could never find useful doc on those, but as far as I
can tell, there's no such support on x86, at least.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Is it possible atlas is linked wrongly by new binutils?

[Dominik 'Rathann' Mierzejewski]

On Monday, 14 August 2017 at 02:35, Kevin Kofler wrote:
> Dominik 'Rathann' Mierzejewski wrote:
> > It also needs some patching, because each library has a different
> > SONAME.
> 
> Symlinking
> libblas.so.3 → libopenblas.so.0
> liblapack.so.3 → libopenblas.so.0
> is enough to get things linked against BLAS and/or LAPACK to pick up 
> OpenBLAS instead. A similar symlinking should work for the -devel package. 
> If the symlinks confuse ldconfig or cause some other issues, linker scripts 
> can be used instead.

It certainly won't be enough for RPM. There needs to be a libblas.so
pointing to a library with SONAME libblas.so.3, same for lapack.

[...]
> It is the job of the distribution to ensure that software uses the most 
> efficient BLAS/LAPACK implementation available. Other distributions ship 
> symlinks ensuring that. The current packaging in Fedora is horrible.

Thinking again, we had this discussion over 3 years ago:
https://pagure.io/packaging-committee/issue/352
and another one starting 2 years ago:
https://pagure.io/packaging-committee/issue/588
which is stalled because Orion doesn't have any time lately.

I'd love to see this done properly, but I don't have enough time to work
on this alone. Are you volunteering to patch all blas/lapack
implementations in Fedora to provide drop-in replacements for each other
and address all the issues mentioned in the above tickets? I would support
such effort and would certainly lend a hand.

It'd definitely be a much more productive use of your time than
complaining here.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPMFusion   http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Is it possible atlas is linked wrongly by new binutils?

[Kevin Kofler]

Dominik 'Rathann' Mierzejewski wrote:
> It also needs some patching, because each library has a different
> SONAME.

Symlinking
libblas.so.3 → libopenblas.so.0
liblapack.so.3 → libopenblas.so.0
is enough to get things linked against BLAS and/or LAPACK to pick up 
OpenBLAS instead. A similar symlinking should work for the -devel package. 
If the symlinks confuse ldconfig or cause some other issues, linker scripts 
can be used instead.

> I think atlas used to provide a drop-in replacement, but it was abandoned

Ouch! Indeed, the current ATLAS packages provide only libsatlas and 
libtatlas, no libblas or liblapack. This is a regression and should never 
have been packaged that way. Now all the packages end up with the 
unoptimized reference BLAS. (In fact, I think I already noticed that when it 
happened and complained loudly about it, but was ignored, as it seems. 
Sigh!)

That said, ATLAS should really go away, unless they add support for runtime 
CPU detection and the result matches or exceeds OpenBLAS performance. In its 
current state (which has been the state since its inception), ATLAS is 
really unsuitable for distribution packaging. They just do not care about 
binary packages, at all.

> on the premise that scientific codes are compiled specifically for their
> target clusters anyway

… which is of course not true for distribution packages!

> and Intel's math library (MKL) doesn't provide a drop-in replacement.

… which is entirely irrelevant.

It is the job of the distribution to ensure that software uses the most 
efficient BLAS/LAPACK implementation available. Other distributions ship 
symlinks ensuring that. The current packaging in Fedora is horrible.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Is it possible atlas is linked wrongly by new binutils?

[Dominik 'Rathann' Mierzejewski]

On Sunday, 13 August 2017 at 14:58, Matthew Miller wrote:
> On Sun, Aug 13, 2017 at 11:01:04AM +0200, Kevin Kofler wrote:
> > Can't we make it a drop-in replacement for reference BLAS/LAPACK and ATLAS, 
> > i.e., having symlinks or linker scripts pointing at least libblas.so and 
> > liblapack.so to libopenblas.so.*, ideally also libblas.so.3 and 
> > liblapack.so.3 so that no rebuilds are necessary and so that things using 
> > dlopen and third-party binary blobs also use OpenBLAS?
> > 
> > The current situation where we have 3 different BLAS implementations and 
> > where for most programs, depending on your setup, you get either the worst 
> > one (reference BLAS) or a suboptimal one (ATLAS compiled for the baseline 
> > architecture), but never the best one (OpenBLAS with runtime CPU 
> > detection), 
> > is a mess.
> 
> This sounds like a good idea (and worthy of a Change). I hate to
> suggest Alternatives but maybe it's appropriate here? 

It also needs some patching, because each library has a different
SONAME. I think atlas used to provide a drop-in replacement, but
it was abandoned on the premise that scientific codes are compiled
specifically for their target clusters anyway and Intel's math library
(MKL) doesn't provide a drop-in replacement.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPMFusion   http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Is it possible atlas is linked wrongly by new binutils?

[Matthew Miller]

On Sun, Aug 13, 2017 at 11:01:04AM +0200, Kevin Kofler wrote:
> Can't we make it a drop-in replacement for reference BLAS/LAPACK and ATLAS, 
> i.e., having symlinks or linker scripts pointing at least libblas.so and 
> liblapack.so to libopenblas.so.*, ideally also libblas.so.3 and 
> liblapack.so.3 so that no rebuilds are necessary and so that things using 
> dlopen and third-party binary blobs also use OpenBLAS?
> 
> The current situation where we have 3 different BLAS implementations and 
> where for most programs, depending on your setup, you get either the worst 
> one (reference BLAS) or a suboptimal one (ATLAS compiled for the baseline 
> architecture), but never the best one (OpenBLAS with runtime CPU detection), 
> is a mess.

This sounds like a good idea (and worthy of a Change). I hate to
suggest Alternatives but maybe it's appropriate here? 

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Is it possible atlas is linked wrongly by new binutils?

[Kevin Kofler]

Dominik 'Rathann' Mierzejewski wrote:
> Yes, you don't need to add -L%{_libdir}/atlas to LDFLAGS anymore and you
> link with -lopenblas.

Can't we make it a drop-in replacement for reference BLAS/LAPACK and ATLAS, 
i.e., having symlinks or linker scripts pointing at least libblas.so and 
liblapack.so to libopenblas.so.*, ideally also libblas.so.3 and 
liblapack.so.3 so that no rebuilds are necessary and so that things using 
dlopen and third-party binary blobs also use OpenBLAS?

The current situation where we have 3 different BLAS implementations and 
where for most programs, depending on your setup, you get either the worst 
one (reference BLAS) or a suboptimal one (ATLAS compiled for the baseline 
architecture), but never the best one (OpenBLAS with runtime CPU detection), 
is a mess.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Is it possible atlas is linked wrongly by new binutils?

[Dominik 'Rathann' Mierzejewski]

On Saturday, 12 August 2017 at 23:30, Richard W.M. Jones wrote:
> On Sat, Aug 12, 2017 at 12:40:18PM +0200, Kevin Kofler wrote:
> > Richard W.M. Jones wrote:
> > > I have no particular affinity for Atlas.  But if we're going to
> > > replace it, is OpenBLAS a complete drop-in replacement for Atlas that
> > > requires no or at least very minimal changes?  In what ways is it better
> > > or worse?
> > 
> > Proper support for runtime CPU feature detection on x86 architectures 
> > (x86_64 and i686). ATLAS expects to be tuned to every single machine, and 
> > distro packages can only be built to the lowest common denominator. 
> > (Anything else can only be in atlas-* subpackages that have to be manually 
> > installed.) OpenBLAS can also do that, but it also has a mode (used in 
> > packaging) where it will check for the available vector instruction sets 
> > (MMX, SSE*, AVX*) and pick the highest one available on the machine that is 
> > implemented for the called function. E.g., it can use SSE3 and newer on 
> > x86_64 when available, without breaking the SSE2-only x86_64 baseline. 
> > (Please note that this is only supported on x86 at this time. For ARM, it 
> > is 
> > like ATLAS, you can only compile for the baseline.) This can make a big 
> > difference in distro packages.
> > 
> > There might also be other performance benefits. OpenBLAS is derived from 
> > GotoBLAS (which was put under a BSD license when Prof. Goto left TACC in 
> > 2010, so that the community can continue development, which is exactly what 
> > OpenBLAS is doing). GotoBLAS has, since its proprietary times, had a 
> > reputation of being a really fast implementation.
> 
> Sounds all good.  Are source-level changes needed to dependent
> packages and if so are they simple to make?

Yes, you don't need to add -L%{_libdir}/atlas to LDFLAGS anymore and you
link with -lopenblas.

See scalapack, arpack or elpa packages for example. In fact, I had to
switch elpa to openblas to match scalapack. Otherwise I got test
failures.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPMFusion   http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Is it possible atlas is linked wrongly by new binutils?

[Richard W.M. Jones]

On Sat, Aug 12, 2017 at 12:40:18PM +0200, Kevin Kofler wrote:
> Richard W.M. Jones wrote:
> > I have no particular affinity for Atlas.  But if we're going to
> > replace it, is OpenBLAS a complete drop-in replacement for Atlas that
> > requires no or at least very minimal changes?  In what ways is it better
> > or worse?
> 
> Proper support for runtime CPU feature detection on x86 architectures 
> (x86_64 and i686). ATLAS expects to be tuned to every single machine, and 
> distro packages can only be built to the lowest common denominator. 
> (Anything else can only be in atlas-* subpackages that have to be manually 
> installed.) OpenBLAS can also do that, but it also has a mode (used in 
> packaging) where it will check for the available vector instruction sets 
> (MMX, SSE*, AVX*) and pick the highest one available on the machine that is 
> implemented for the called function. E.g., it can use SSE3 and newer on 
> x86_64 when available, without breaking the SSE2-only x86_64 baseline. 
> (Please note that this is only supported on x86 at this time. For ARM, it is 
> like ATLAS, you can only compile for the baseline.) This can make a big 
> difference in distro packages.
> 
> There might also be other performance benefits. OpenBLAS is derived from 
> GotoBLAS (which was put under a BSD license when Prof. Goto left TACC in 
> 2010, so that the community can continue development, which is exactly what 
> OpenBLAS is doing). GotoBLAS has, since its proprietary times, had a 
> reputation of being a really fast implementation.

Sounds all good.  Are source-level changes needed to dependent
packages and if so are they simple to make?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Is it possible atlas is linked wrongly by new binutils?

[Kevin Kofler]

Richard W.M. Jones wrote:
> I have no particular affinity for Atlas.  But if we're going to
> replace it, is OpenBLAS a complete drop-in replacement for Atlas that
> requires no or at least very minimal changes?  In what ways is it better
> or worse?

Proper support for runtime CPU feature detection on x86 architectures 
(x86_64 and i686). ATLAS expects to be tuned to every single machine, and 
distro packages can only be built to the lowest common denominator. 
(Anything else can only be in atlas-* subpackages that have to be manually 
installed.) OpenBLAS can also do that, but it also has a mode (used in 
packaging) where it will check for the available vector instruction sets 
(MMX, SSE*, AVX*) and pick the highest one available on the machine that is 
implemented for the called function. E.g., it can use SSE3 and newer on 
x86_64 when available, without breaking the SSE2-only x86_64 baseline. 
(Please note that this is only supported on x86 at this time. For ARM, it is 
like ATLAS, you can only compile for the baseline.) This can make a big 
difference in distro packages.

There might also be other performance benefits. OpenBLAS is derived from 
GotoBLAS (which was put under a BSD license when Prof. Goto left TACC in 
2010, so that the community can continue development, which is exactly what 
OpenBLAS is doing). GotoBLAS has, since its proprietary times, had a 
reputation of being a really fast implementation.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Is it possible atlas is linked wrongly by new binutils?

[Richard W.M. Jones]

On Sat, Aug 12, 2017 at 12:11:00AM +0200, Dominik 'Rathann' Mierzejewski wrote:
> On Thursday, 10 August 2017 at 12:29, Richard W.M. Jones wrote:
> > Never mind.  Something in the atlas build segfaults when building
> > on ppc64le:
> > 
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=21145734
> > 
> > This is a mess :-(
> 
> Just switch to openblas already. ;)

I have no particular affinity for Atlas.  But if we're going to
replace it, is OpenBLAS a complete drop-in replacement for Atlas that
requires no or at least very minimal changes?  In what ways is it better
or worse?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Is it possible atlas is linked wrongly by new binutils?

[Dominik 'Rathann' Mierzejewski]

On Thursday, 10 August 2017 at 12:29, Richard W.M. Jones wrote:
> Never mind.  Something in the atlas build segfaults when building
> on ppc64le:
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=21145734
> 
> This is a mess :-(

Just switch to openblas already. ;)

I'd propose a Change for F28 to switch to openblas
as the default implementation if I had some help.
Any volunteers?

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPMFusion   http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Is it possible atlas is linked wrongly by new binutils?

[Jakub Martisko]

Well, yes, the current version is a bit messy, I am
currently working on rebase to 3.10.3, where the builds seem
to be more stable but I wanted to test it a bit more before
publishing it tbh. :-/

On 10.8.2017 12:29, Richard W.M. Jones wrote:
> Never mind.  Something in the atlas build segfaults when building
> on ppc64le:
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=21145734
> 
> This is a mess :-(
> 
> Rich.
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Is it possible atlas is linked wrongly by new binutils?

[Richard W.M. Jones]

Never mind.  Something in the atlas build segfaults when building
on ppc64le:

https://koji.fedoraproject.org/koji/taskinfo?taskID=21145734

This is a mess :-(

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Is it possible atlas is linked wrongly by new binutils?

[Richard W.M. Jones]

On Thu, Aug 10, 2017 at 11:21:30AM +0200, Jakub Martisko wrote:
> 
> 
> On 9.8.2017 11:37, Richard W.M. Jones wrote:
> > 
> > ocaml-gsl (OCaml bindings for GNU Scientific Library) currently
> > fails to link to atlas:
> > 
> > + /usr/bin/ocamlfind ocamlopt -g -I lib -linkpkg -package bigarray -I lib 
> > -I examples lib/gsl.cmxa examples/blas_ex.cmx -o examples/blas_ex.native
> > /usr/lib64/atlas/libsatlas.so: undefined reference to `dlarfy_'
> > /usr/lib64/atlas/libsatlas.so: undefined reference to `slarfy_'
> > /usr/lib64/atlas/libsatlas.so: undefined reference to `clarfy_'
> > /usr/lib64/atlas/libsatlas.so: undefined reference to `zlarfy_'
> > collect2: error: ld returned 1 exit status
> > 
> > However this only happens with the very latest atlas that was built by
> > binutils 2.29 (atlas-3.10.2-18.fc27.x86_64).  It doesn't occur with
> > the previous version of atlas (atlas-3.10.2-16.fc26) even though there
> > seems to have been no change in atlas.
> > 
> > $ nm -D /usr/lib64/atlas/libtatlas.so | grep larfy
> >  U clarfy_
> >  U dlarfy_
> >  U slarfy_
> >  U zlarfy_
> > 
> > I looked in /usr/lib64 on my development machine which has atlas
> > installed but there is no .so* file that I can find which defines
> > these symbols.  I also couldn't work out where in the atlas code
> > (which is a bit strange) these references are used.
> > 
> > Hence the question: Is this breakage in atlas?  binutils?
> > 
> > Rich.
> > 
> 
> OK so it seems that according to git commit messages LAPACK
> has been rebased from 3.6.0 to 3.7.1 day before that mass
> rebuild [1][2]. Those "larfy" subroutines have been added to
> LAPACK in 3.7.0 and have not been present before[3]. I've
> tried to make a scratch build of atlas [4] and the missing
> symbols seem to be present...
> 
> $ nm -D ./libtatlas.so.3|grep larfy
> 
> T clarfy_
> T dlarfy_
> T slarfy_
> T zlarfy_

It looks as if you scratch build just changes ‘rm’ to ‘rm -f’ at one
point in the spec file.  Is that change also needed?

I can do a bump and rebuild of atlas with or without that change - let
me know.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Is it possible atlas is linked wrongly by new binutils?

[Richard W.M. Jones]

On Wed, Aug 09, 2017 at 02:10:02PM +0200, Antonio Trande wrote:
> On 08/09/2017 11:37 AM, Richard W.M. Jones wrote:
> > 
> > ocaml-gsl (OCaml bindings for GNU Scientific Library) currently
> > fails to link to atlas:
> > 
> > + /usr/bin/ocamlfind ocamlopt -g -I lib -linkpkg -package bigarray -I lib 
> > -I examples lib/gsl.cmxa examples/blas_ex.cmx -o examples/blas_ex.native
> > /usr/lib64/atlas/libsatlas.so: undefined reference to `dlarfy_'
> > /usr/lib64/atlas/libsatlas.so: undefined reference to `slarfy_'
> > /usr/lib64/atlas/libsatlas.so: undefined reference to `clarfy_'
> > /usr/lib64/atlas/libsatlas.so: undefined reference to `zlarfy_'
> > collect2: error: ld returned 1 exit status
> > 
> > However this only happens with the very latest atlas that was built by
> > binutils 2.29 (atlas-3.10.2-18.fc27.x86_64).  It doesn't occur with
> > the previous version of atlas (atlas-3.10.2-16.fc26) even though there
> > seems to have been no change in atlas.
> > 
> > $ nm -D /usr/lib64/atlas/libtatlas.so | grep larfy
> >  U clarfy_
> >  U dlarfy_
> >  U slarfy_
> >  U zlarfy_
> > 
> > I looked in /usr/lib64 on my development machine which has atlas
> > installed but there is no .so* file that I can find which defines
> > these symbols.  I also couldn't work out where in the atlas code
> > (which is a bit strange) these references are used.
> > 
> > Hence the question: Is this breakage in atlas?  binutils?
> > 
> > Rich.
> > 
> 
> lapack-3.7.1 on rawhide looks affected too:
> https://bugzilla.redhat.com/show_bug.cgi?id=1479567

As is ocaml-lacaml (OCaml bindings for lapack) ...

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Is it possible atlas is linked wrongly by new binutils?

[Jerry James]

On Wed, Aug 9, 2017 at 3:37 AM, Richard W.M. Jones  wrote:
>
> ocaml-gsl (OCaml bindings for GNU Scientific Library) currently
> fails to link to atlas:
>
> + /usr/bin/ocamlfind ocamlopt -g -I lib -linkpkg -package bigarray -I lib -I 
> examples lib/gsl.cmxa examples/blas_ex.cmx -o examples/blas_ex.native
> /usr/lib64/atlas/libsatlas.so: undefined reference to `dlarfy_'
> /usr/lib64/atlas/libsatlas.so: undefined reference to `slarfy_'
> /usr/lib64/atlas/libsatlas.so: undefined reference to `clarfy_'
> /usr/lib64/atlas/libsatlas.so: undefined reference to `zlarfy_'
> collect2: error: ld returned 1 exit status

Something is definitely afoot.  The latest opengrm-ngram build just
failed with the same list of undefined symbols.
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Is it possible atlas is linked wrongly by new binutils?

[Antonio Trande]

On 08/09/2017 11:37 AM, Richard W.M. Jones wrote:
> 
> ocaml-gsl (OCaml bindings for GNU Scientific Library) currently
> fails to link to atlas:
> 
> + /usr/bin/ocamlfind ocamlopt -g -I lib -linkpkg -package bigarray -I lib -I 
> examples lib/gsl.cmxa examples/blas_ex.cmx -o examples/blas_ex.native
> /usr/lib64/atlas/libsatlas.so: undefined reference to `dlarfy_'
> /usr/lib64/atlas/libsatlas.so: undefined reference to `slarfy_'
> /usr/lib64/atlas/libsatlas.so: undefined reference to `clarfy_'
> /usr/lib64/atlas/libsatlas.so: undefined reference to `zlarfy_'
> collect2: error: ld returned 1 exit status
> 
> However this only happens with the very latest atlas that was built by
> binutils 2.29 (atlas-3.10.2-18.fc27.x86_64).  It doesn't occur with
> the previous version of atlas (atlas-3.10.2-16.fc26) even though there
> seems to have been no change in atlas.
> 
> $ nm -D /usr/lib64/atlas/libtatlas.so | grep larfy
>  U clarfy_
>  U dlarfy_
>  U slarfy_
>  U zlarfy_
> 
> I looked in /usr/lib64 on my development machine which has atlas
> installed but there is no .so* file that I can find which defines
> these symbols.  I also couldn't work out where in the atlas code
> (which is a bit strange) these references are used.
> 
> Hence the question: Is this breakage in atlas?  binutils?
> 
> Rich.
> 

lapack-3.7.1 on rawhide looks affected too:
https://bugzilla.redhat.com/show_bug.cgi?id=1479567

-- 
--
Antonio Trande
sagitter AT fedoraproject dot org
See my vCard.
<>

signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org