IƱaki Ucar <iucar(a)fedoraproject.org> writes:
> The licence seems to me to
> rule it out a priori.
The authors are going to add an exception, so the license won't be a
problem. What problems do you think it produces?
Obviously GPLv3 is incompatible with GPLv2, for instance, and typically
with other strong copyleft.
> The proposal doesn't justify things, including its dismissal
of the
> simple, clean alternative in similar to Debian's, with which I have some
I don't justify that because Debian's alternative has been repeatedly
dismissed as an option for Fedora for a simple reason: one could end
up with libblas pointing to one implementation and liblapack pointing
to another. This problem, that Debian has, is solved with this
library.
You'll have to explain; I'd have thought the explanation should have
been in the proposal. I don't know what it means to have "another
implementation" of LAPACK in relation to BLIS for example. I explicitly
want to be able to substitute LAPACK and BLAS implementations, including
serial and OpenMP.
> There will be hoops to jump through to get packages to configure
when
> they don't know about the library.
I don't think so, but if there are serious issues, rolling back the
change is pretty straightforward.
That sounds like insufficient experience!
> If I want to use a library that's
> not included, I'm in the same position.
No, you are not. You just need to point to that library using the
FLEXIBLAS environment variable.
I'm unclear on exactly how flexiblas currently works, but the above
seems to be saying that I must have a limited choice of BLAS and LAPACK
anyway. I can flip an environment variable already to subvert other
BLASs with BLIS. (I considered dynamically loading different
implementations when I tackled this initially.) Setting the environment
other than explicitly in a batch script isn't necessarily easy or robust
anyway, as opposed to ldconfig on sets of nodes.
> It's not clear to me a priori
> what happens if you try to use just BLIS even, given that OpenBLAS'
> LAPACK implementation isn't the vanilla one, and depends on OpenBLAS as
> far as I know.
I don't understand this. You can switch to BLIS easily. The default
one doesn't matter.
See above about an independent choice of BLAS and LAPACK. What happens
if I want to use BLIS functions and link against a library that's using
OpenBLAS and don't know about whatever magic I need in the environment
to make it work?
> The choice of OpenBLAS isn't justified. It's not even
> obvious that you want the same implementation for serial and
> multi-threaded as OpenBLAS seems to have had continual problems with
> threading which BLIS hasn't as far as I know. I expect OpenBLAS is the
> best serial option on average, at least, but that needs data for
> different architectures.
This is about having a sane default one. That's it. You can switch
then to whatever implementation you want.
So what's the basis for choosing the default?
https://github.com/flame/blis/blob/80e6c10b72d50863b4b64d79f784df7befedfc...
for instance? An OpenMP default that performs serially if you set
OMP_NUM_THREADS and OMP_PROC_BIND doesn't seem a sane default. Again
this seems to be saying I can switch things at will, despite what it
says above, and that the mechanism is robust.
> I realize no-one is going to be running Fedora on HPC systems,
where
> this really matters, but presumably it filters down to RHEL, which is
> looking less and less like a good HPC platform to me.
Actually, FlexiBLAS is developed by researchers in HPC.
I know. That doesn't necessarily mean they have substantial experience
of HPC research support, system management, and packaging; that helps
when evaluating any necessary engineering trades-off. (If I listened to
the HPC mainstream on software provision, I wouldn't be a packager and
wouldn't have had a easily manageable cluster.) I'm waiting to be
convinced what I've concluded from R&D is invalid.