Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Getting BLIS into Ubuntu #210

Closed
fgvanzee opened this issue May 22, 2018 · 31 comments
Closed

Getting BLIS into Ubuntu #210

fgvanzee opened this issue May 22, 2018 · 31 comments

Comments

@fgvanzee
Copy link
Member

Robert asked me recently, "What would it take for BLIS to be incorporated into Ubuntu?"

Some light Googling lead me to understand that there are four main repositories in Ubuntu: main, restricted, universe, multiverse. It sounds like we would be okay being in universe at least at first, especially if we need more time to prove ourselves suitable for main.

I then found this stackexchange thread on the topic. The most up-voted response breaks down some of the options. It appears that getting into Debian is the most comprehensive choice (also indicated here), as it would mean BLIS would be made available to users of both Linux distributions (Debian and Ubuntu).

Thanks to the work of Nico Schlömer, we already have someone involved with the project who knows how to create (and has created) PPA packages. The biggest hurdle, it seems, is to get a Debian Developer (DD) to become our sponsor. This begins with a Request-for-Sponsor (RFS) bug report in Debian's bug-tracking system. (The RFS is like an ad designed to pique the interest of developer to become our sponsor.) But we are not supposed to submit the RFS until we have our source package ready for a potential sponsor to download/build/install. I think, thanks to Nico's work, we are basically there. (Care the comment, @nschloe?)

Note that there is no guarantee that we will find a sponsor. There are a finite number of DDs, each with limited time and specific specializations/interests/preferences.

After we get a sponsor, I think we will need this sponsor to upload any future revisions of the package. This is probably the most concerning to me aspect to me since BLIS has been undergoing relatively frequent updates.

Bottom line, this appears to be a non-trivial amount of work. So we should discuss/think carefully about if and when this would make sense for us.

Please comment, if you like.
@devinamatthews
Copy link
Member

Regarding having BLIS in a PPA (either Debian or Ubuntu, or does it matter?): on OpenSUSE there are the regular packages in the "official" repos, but there are also "1-Click" install files which prompt the package manager to both add an external package repo (the PPA in our case) and then install the package. Does something like this exist for Debian/Ubuntu? The upside of this would be not needing to get into the official repo but also making it easy for users to install and get updates. If we don't care about the second part then a bare .deb/.rpm would also suffice.

@fgvanzee
Copy link
Member Author

Does something like this exist for Debian/Ubuntu?

@devinamatthews According to this wiki, it appears that the answer is yes (see section "Adding Personal Package Archives (PPAs)"). However, this may not so much as capture new users as give some of the existing ones another installation option. The way I see it, if the person is willing to pre-configure their Ubuntu GUI package widget to download from, say, Nico's PPA, they would probably already be willing to go straight to GitHub, especially since the latter would allow them access too all configuration options, whereas a binary would restrict them to whatever choices the package maintainer made.

@devinamatthews
Copy link
Member

The "1-Click" thing is slightly different in that one can just have a link on a webpage that the user clicks on, and then everything is automated from there. Adding a PPA manually to Ubuntu is relatively much more of a PITA.

@fgvanzee
Copy link
Member Author

@devinamatthews Understood, sorry for that nuance being lost on me. (I've never used OpenSuSE.)

@nschloe
Copy link
Contributor

nschloe commented May 23, 2018

I myself am a Debian Maintainer (DM) so I have a fair idea of how things are working. A package gets into Debian if (a) it's popular enough for people to want it or (b) if another package depends on it. This approach is typically taken somewhat conservatively since if you're volunteering to maintain a package, it's your task forever. For example, even though I follow BLIS with great interest, I myself wouldn't want to dive into that yet.

If your goal is to get BLIS into Ubuntu, you're already there: There's a PPA, and everyone is just one command away to add it.

If you want to gain some traction, one way would probably be to demonstrate that you do some things better (faster?) than BLAS, given developers of other software arguments for linking against BLIS rather than BLAS. Perhaps get back to SciPy or NumPy, they'll be able to give you some good feedback.

@loveshack
Copy link
Contributor

I think a Debian package should do the same as the openblas one and provide libblas.so.3, to be substitutable at run time (the way the BLIS rpm packaging does). I started doing that along with the rpm spec, but it wasn't clear to me what the actual Debian linear algebra policy is, as I commented somewhere in the issues. Also, I don't like Debian only offering a pthreads version of openblas, not serial or OpenMP, which you probably want for HPC. (I think that was purely for support of numpy for some reason I don't remember, but I don't see why it should exclude the others.)

The specific reason to have BLIS included is the KNL and SKX BLAS support, which OpenBLAS doesn't have.

@fgvanzee
Copy link
Member Author

@loveshack Curious: Why is the soname of the shared library chosen to be 3 (in libblas.so.3)?

@loveshack
Copy link
Contributor

loveshack commented May 31, 2018 via email

@fgvanzee
Copy link
Member Author

Thanks Dave, but I guess my question is why is it a convention that libblas.so.3 use an soname of 3? Is it because BLAS did not change after the introduction of the level-3 operations? I can't help but notice that all of the other netlib libraries seem to use an soname of 3 as well. Maybe it has to do with the current major version number of LAPACK? (It's okay if you don't know the answer.)

@loveshack
Copy link
Contributor

loveshack commented Jun 1, 2018 via email

@fgvanzee
Copy link
Member Author

fgvanzee commented Jun 1, 2018

@loveshack Okay, sounds like the "3" is just coincidence then.

(A library increasing its soname occasionally is not surprising to me. But my question was motivated by the fact that I was under the impression that netlib BLAS, which is what I think of when I see libblas, simply did not experience the kinds of changes that would break its ABI, since it was unrolled in a way that did not break old functionality, but rather just added new operations. But I can sleep fine not getting to the bottom of this one.)

@fgvanzee
Copy link
Member Author

fgvanzee commented Jun 4, 2018

@loveshack Do you see any issue with simply providing a symbolic link named libblas.so.3? I'm not totally in love with this idea, mostly due to the aliasing of the soname of 3 onto libblis's (current) soname of 0, but I'm nevertheless open to a symlink.

@loveshack
Copy link
Contributor

loveshack commented Jun 4, 2018 via email

@loveshack
Copy link
Contributor

loveshack commented Jun 4, 2018 via email

@fgvanzee
Copy link
Member Author

fgvanzee commented Jun 4, 2018

For what purpose? It won't work as a dynamic substitute for the original libblas.so.3 because the ELF soname is wrong.

Okay, I suppose I hadn't thought of that.

Hope there aren't any hard feelings, Dave, and that you understand that I'm just trying to balance our own project's conventions with how far we bend over backwards to accommodate existing BLAS conventions (beyond the BLAS API itself). We appreciate your involvement. Let us know how the Fedora thing goes.

@loveshack
Copy link
Contributor

loveshack commented Jun 7, 2018 via email

@fgvanzee
Copy link
Member Author

fgvanzee commented Jun 7, 2018

I was trying to avoid you having to! I don't particularly expect it to be in the BLIS distribution, but if it isn't in distributions, it's most useful there, and I'd think most people's interest will be in BLAS for existing applications.

My apologies, I misunderstood. I thought you wanted BLIS to create a libblas.so.3 as part of its standard make install. It sounds like you were instead proposing that this be a feature of the rpm? (If so, we are completely fine with that.)

Are there applications using BLIS directly which could be mentioned?

By using BLIS directly, I take it you mean the "native" (typed- or object-based) BLIS APIs? We're not sure who are users are or what they might be using it for, though it's something we would love to know more about. Unfortunately, github doesn't do a great job of facilitating us to "track" our users or their use cases (perhaps understandably given the premium people place on privacy as of late).

@loveshack
Copy link
Contributor

loveshack commented Jun 18, 2018 via email

@fgvanzee
Copy link
Member Author

By using BLIS directly, I take it you mean the "native" (typed- or object-based) BLIS APIs?

Yes, that's what I meant.

I wish I could give you an emphatic "yes," but to be honest we just don't know. We hope there will be plenty of applications in the future that make use of the native interfaces.

I'll try to have another look at making the Debian packaging consistent with openblas' if that would be useful.

Feel free to do so (at your own pace). We welcome your contributions.

Sorry for the delay -- been ill.

No worries. Hope you are feeling better.

@cdluminate
Copy link
Contributor

cdluminate commented Sep 24, 2018 •
edited
Loading

@nschloe If you have enough time to continue working on BLIS packaging, I can sponsor it for you. This is the initial checklist:

  • create packaging repo on salsa.debian.org and push your commits.
  • register libblis.so as an candidate of libblas.so.3 via the alternatives system.
  • ...

@nschloe
Copy link
Contributor

nschloe commented Sep 25, 2018

If you have enough time to continue working on BLIS packaging,

That could take a while. If you want quick progress, you just go ahead, take the debian folder from this repo and upload it yourself.

@cdluminate
Copy link
Contributor

@nschloe I've already got MKL into Debian official repo and I have many other packages to care. So I expect somebody else other than me to finish this package.

@cdluminate
Copy link
Contributor

@nschloe Hmm..... I've almost finished the package. Please have a look at https://salsa.debian.org/science-team/blis .

@nschloe
Copy link
Contributor

nschloe commented Sep 27, 2018

@cdluminate Looks good to me.

@loveshack
Copy link
Contributor

loveshack commented Sep 27, 2018 via email

@cdluminate
Copy link
Contributor

@loveshack We have created subdirectories for different BLAS implementation so that one could use LD_* to override the default blas/lapack library. I forgot to add such a subdirectory for BLIS though.

~ ❯❯❯ find /usr/lib/x86_64-linux-gnu/ | rg libblas.so.3                                                                                                                                       
/usr/lib/x86_64-linux-gnu/atlas/libblas.so.3
/usr/lib/x86_64-linux-gnu/atlas/libblas.so.3.10.3
/usr/lib/x86_64-linux-gnu/libblas.so.3
/usr/lib/x86_64-linux-gnu/mkl/libblas.so.3                                                                                                                                                    
/usr/lib/x86_64-linux-gnu/openblas/libblas.so.3                                                                                                                                               
/usr/lib/x86_64-linux-gnu/blas/libblas.so.3                                                                                                                                                   
/usr/lib/x86_64-linux-gnu/blas/libblas.so.3.8.0

With some additional work producing three versions of libraries is possible, i.e. libblis-serial, libblis-pthread, and libblis-openmp.

I'm not sure what you mean exactly by I'd expect to be able to substitute any BLAS(/LAPACK), but Debian has an alternatives system which could change the default blas/lapack backend for the system.

~ ❯❯❯ sudo update-alternatives --config libblas.so-x86_64-linux-gnu                                                                                                                           
There are 4 choices for the alternative libblas.so-x86_64-linux-gnu (providing /usr/lib/x86_64-linux-gnu/libblas.so).

  Selection    Path                                           Priority   Status                                                                                                               
------------------------------------------------------------                                                                                                                                  
  0            /usr/lib/x86_64-linux-gnu/openblas/libblas.so   40        auto mode                                                                                                            
  1            /usr/lib/x86_64-linux-gnu/blas/libblas.so       10        manual mode                                                                                                          
  2            /usr/lib/x86_64-linux-gnu/libblis.so            37        manual mode                                                                                                          
* 3            /usr/lib/x86_64-linux-gnu/libmkl_rt.so          1         manual mode                                                                                                          
  4            /usr/lib/x86_64-linux-gnu/openblas/libblas.so   40        manual mode                                                                                                          
                                                                                                                                                                                              
Press <enter> to keep the current choice[*], or type selection number: ^C⏎

@cdluminate
Copy link
Contributor

@loveshack This page is not a "policy" https://wiki.debian.org/DebianScience/LinearAlgebraLibraries

@loveshack
Copy link
Contributor

loveshack commented Oct 1, 2018 via email

@loveshack
Copy link
Contributor

loveshack commented Oct 1, 2018 via email

@cdluminate
Copy link
Contributor

BLIS is automatically synced into Ubuntu devel branch (current codename: disco) https://launchpad.net/ubuntu/+source/blis

Maybe this issue can be closed now.

@fgvanzee
Copy link
Member Author

@cdluminate Agreed. Thanks for the nudge.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@nschloe @devinamatthews @fgvanzee @cdluminate @loveshack