Re: OpenBLAS and performance

For what it's worth, I get 37000 Mflops from the dgemm.goto benchmark using the current Guix openblas and OPENBLAS_NUM_THREADS=1 at a size of 7000 on a laptop with "i5-6200U CPU @ 2.30GHz" (avx2). That looks about right, and it should more-or-less plateau at that size. For comparison, I get

Re: OpenBLAS and performance

Ludovic Courtès <ludovic.cour...@inria.fr> writes: > Hello, > > Dave Love <f...@gnu.org> skribis: > >> Fedora sensibly builds separately-named libraries for different flavours >> <https://apps.fedoraproject.org/packages/openblas/sources/>, but I'd

Re: OpenBLAS and performance

Ricardo Wurmus writes: >> I was confused. I see the only version of the library shipped is built >> with pthreads. I think there should be serial, pthreads, and OpenMP >> versions, as for Fedora. > > Do these library variants have the same binary interface, so that a user >

Re: OpenBLAS and performance

Eric Bavier writes: > Related only to this specific case of BLAS libraries, and not to the > general idea of optimized libraries: > I recently discovered "FlexiBLAS" from the Max Planck Institute > https://www.mpi-magdeburg.mpg.de/projects/flexiblas which I thought >

Re: OpenBLAS and performance

Ricardo Wurmus writes: > Hi Pjotr, > >> I was just stating that the default openblas package does not perform >> well (it is single threaded, for one). > > Is it really single-threaded? I remember having a couple of problems > with OpenBLAS on our cluster when it is used

Re: OpenBLAS and performance

I wrote: > If you do provide some sort of threaded version for Python, then as far > as I remember it must use pthreads, not OpenMP, though you want the > OpenMP version for other purposes, and I hadn't realized there wasn't > one currently. I was confused. I see the only version of the

Re: OpenBLAS and performance

Pjotr Prins writes: > The last weeks I have been toying with OpenBlas and tweaking it boosts > performance magnificently over the standard install we do now. How so? I haven't measured it from Guix, but I have with Fedora packages, and OB is basically equivalent to

Re: avoid wrapper scripts when possible

Ricardo Wurmus writes: > For binaries (like emacs) we’d still create shell wrappers where needed, > because it’s harder to do this natively. You could link in a constructor function to replace a wrapper that just sets the environment, couldn't you? I've done that at times

Re: Tiny Guix (and containers)

Ludovic Courtès writes: >> It looks to me as if it would often help significantly, e.g. when a >> pkg-config file, or something else sucks in a load of stuff that's >> irrelevant for running the package. (Separating :lib and needing that >> for building means you need to know

Re: why is linux-libre-headers behind linux-libre?

Pjotr Prins writes: > The Linux kernel API is remarkably stable. Actually, I don't think that's the case, speaking as someone who's had to deal with out-of-tree drivers for various reasons. For instance, the OrangeFS module typically broke when I tried to rebuild the

Re: why is linux-libre-headers behind linux-libre?

Ludovic Courtès writes: > The Omnipath library relies on Linux (not libc) headers, and a specific > version thereof? The current version of the library relies on a recent enough version of the module/headers as it's fairly new stuff. It's interacting with the driver at a fairly

Re: Tiny Guix (and containers)

Ludovic Courtès writes: > Another reason is that splitting is just part of the story. Often, it’s > not moving out 10 KB of header files that really helps; rather, it’s > stripping the dependency graph. Oh, sure, and that probably isn't the reason for convention of splitting

Re: Tiny Guix (and containers)

Pjotr Prins writes: > For most software we just need the binary executable and its shared > libs. That is exactly what I package with my tool: > > For gemma the binary closure is only 18Mb. See > https://github.com/genetics-statistics/GEMMA/issues/90 > > That is small.

Re: Hacks to install Guix packages without root

Pjotr Prins <pjotr.publi...@thebird.nl> writes: > On Tue, Oct 31, 2017 at 02:19:55PM +0000, Dave Love wrote: >> Pjotr Prins <pjotr.publi...@thebird.nl> writes: >> >> > PRoot is too slow for most HPC purposes but can be used to build >> > non-pr

Re: why is linux-libre-headers behind linux-libre?

Efraim Flashner <efr...@flashner.co.il> writes: > On Tue, Oct 31, 2017 at 02:00:35PM +0100, Vincent Legoll wrote: >> Hello, >> >> On Tue, Oct 31, 2017 at 1:35 PM, Dave Love <f...@gnu.org> wrote: >> > Why is linux-libre-headers a long way behind lin

Re: Hacks to install Guix packages without root

Pjotr Prins writes: > PRoot is too slow for most HPC purposes but can be used to build > non-proot binaries, as I do here: > > https://gitlab.com/pjotrp/guix-notes/blob/master/GUIX-NO-ROOT.org I've never tried to measure it, but how does it affect most HPC purposes?

Re: Tiny Guix (and containers)

l...@gnu.org (Ludovic Courtès) writes: > Hi, > > Hartmut Goebel skribis: >> I'm in favor of (automatically?) splitting of "development" packages, >> including the headers and the static libs (much like the "-devel" or >> "-dev" packages in other distributions. One

Re: Tiny Guix (and containers)

Pjotr Prins writes: > But, really, I think when talking embedded systems and containers we > all want tiny. Even HPC can benefit. Tiny containers may be an > attractive proposition. Yes, containers aside, dependencies in Guix are one of the reasons I'm currently

why is linux-libre-headers behind linux-libre?

Why is linux-libre-headers a long way behind linux-libre (currently at version 4.4.47, compared with 4.13.10 for linux-libre)? I ask because current OmniPath fabric support ("psm2") won't build against it, so I wonder if it can be updated. Maybe other recent hardware support will be similar. (I

Re: missing licence files and incomplete licence lists

Ludovic Courtès writes: > If you look at , you’ll see > “License:LGPL”, which is already more vague than what we have (following > FSF legal advice?). If you look at GitHub repos (yack!), Pypi, CPAN, > Hackage, npm (doh!), well, that’s

Re: Question about multiple licenses

Andy Wingo writes: > More concretely... if this is necessary (and I suspect but don't know > that it is,) probably the easiest thing would be for each package to > install a copyright file in its output derivations. Then a "guix pack" > would include them automatically. It

Re: Question about multiple licenses

Ludovic Courtès writes: >> Well, from what I know about copyright, that isn't the licence of glibc, >> which is the sum of all the licences involved, and you'd have to know >> how to find them if you didn't just unpack the tarball. With pack >> output in a lot of cases you don't

Re: blis

Efraim Flashner writes: > I admit, looking at the commit, I'm a little jealous that there wasn't > an aarch64 special version. I checked in $repo/config¹ and there's a > config folder for armv7a, armv8a and longsoon3a, among other options. It > might be worth having some

Re: Packaging BLIS

ludovic.cour...@inria.fr (Ludovic Courtès) writes: > That caught my attention so I packaged BLIS: > > > https://git.savannah.gnu.org/cgit/guix.git/commit/?id=5a7deb117424ff4d430b771b50e534cf065c0ba1 > > There are several “flavors” of BLIS, so you can always rebuild your > favorite program

Re: missing licence files and incomplete licence lists

Ludovic Courtès <l...@gnu.org> writes: > Hi, > > Dave Love <f...@gnu.org> skribis: > >> I realize that a lot of packages don't include licence files >> (e.g. glibc). > > You mean ‘COPYING’ & co.? Yes. >> I'd mistakenly assumed that was auto

Re: Question about multiple licenses

Alex Vong <alexvong1...@gmail.com> writes: > Dave Love <f...@gnu.org> writes: > >> Indeed. Not only do you need to list the licences (according to all >> "legal advice" I've seen for distributions), but normally also >> distribute the releva

Re: Question about multiple licenses

Ludovic Courtès <l...@gnu.org> writes: > Dave Love <f...@gnu.org> skribis: > >> Alex Vong <alexvong1...@gmail.com> writes: >> >>> Based on the above general argument, I think we should list all the >>> licenses instead of just GPLv2+ since it

Re: Question about multiple licenses

Alex Vong writes: > Based on the above general argument, I think we should list all the > licenses instead of just GPLv2+ since it would be inaccurate to say that > the whole program is under just GPLv2+. Indeed. Not only do you need to list the licences (according to

Re: Optionally using more advanced CPU features

Ludovic Courtès writes: >> That may be the best way to handle it, but it's not widely available, >> and isn't possible generally (as far as I know), e.g. for Fortran code. >> See also below. This issue surfaced again recently in Fedora. > > Right. Do you have examples

Re: Optionally using more advanced CPU features

ludovic.cour...@inria.fr (Ludovic Courtès) writes: > Hi, > > Ricardo Wurmus skribis: > >> I was wondering how we should go about optionally building software for >> more advanced CPU features. Currently, we build software for the lowest >> common feature set among x86_64

missing licence files and incomplete licence lists

I realize that a lot of packages don't include licence files (e.g. glibc). I'd mistakenly assumed that was automated according to the "license" fields. Also, some license fields aren't complete -- compare glibc's lgpl with the contents of Debian's libc6 "copyright" file, which includes gpl, bsd,

Re: Open MPI keeps references to GCC, GFortran, etc.

Ludovic Courtès writes: > My intent was to remove the *run-time* dependency of openmpi on gcc & > co. (as returned by ‘guix gc --references’ or ‘guix size openmpi’.) OK, I can send that, though there might still be a case for a separate runtime output. >> Looking at

Re: Open MPI keeps references to GCC, GFortran, etc.

Ludovic Courtès <ludovic.cour...@inria.fr> writes: > Hi, > > Dave Love <f...@gnu.org> skribis: > >> Ludovic Courtès <ludovic.cour...@inria.fr> writes: >> >>> Hello, >>> >>> Open MPI retains references to GCC, GFortran, etc., whi

Re: Open MPI keeps references to GCC, GFortran, etc.

Ludovic Courtès writes: > Hello, > > Open MPI retains references to GCC, GFortran, etc., which significantly > increases its closure size. My query about cycles from separating the lib output was from looking at basically this. There should be a runtime package for