From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludovic.courtes@inria.fr (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: OpenBLAS and performance Date: Fri, 22 Dec 2017 16:10:39 +0100 Message-ID: <87tvwi94sw.fsf@inria.fr> References: <20171219104956.GB806@thebird.nl> <87tvwl7h4w.fsf@albion.it.manchester.ac.uk> <87ind05dwm.fsf@gnu.org> <87vagz0w4y.fsf@albion.it.manchester.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:50971) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eSOyG-0002p8-Qd for guix-devel@gnu.org; Fri, 22 Dec 2017 10:10:50 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eSOyC-0002gF-6r for guix-devel@gnu.org; Fri, 22 Dec 2017 10:10:48 -0500 In-Reply-To: <87vagz0w4y.fsf@albion.it.manchester.ac.uk> (Dave Love's message of "Fri, 22 Dec 2017 12:45:01 +0000") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Dave Love Cc: Guix-devel , Eric Bavier , Federico Beffa Hi, Dave Love skribis: > Ludovic Court=C3=A8s writes: > >> Hello, >> >> Dave Love skribis: >> >>> Fedora sensibly builds separately-named libraries for different flavours >>> , but I'd >>> argue also for threaded versions being available with the generic soname >>> in librray sub-directories. There's some discussion and measurements >>> (apologies if I've referenced it before) at >>> >> >> I like the idea of an =E2=80=98update-alternative=E2=80=99 kind of appro= ach for >> interchangeable implementations. > > /etc/ld.so.conf.d normally provides a clean way to flip the default, > but that isn't available in Guix as far as I remember. Right. >> Unfortunately my understanding is that implementations aren=E2=80=99t en= tirely >> interchangeable, especially for LAPACK (not sure about BLAS), because >> BLIS, OpenBLAS, etc. implement slightly different subsets of netlib >> LAPACK, AIUI. > > LAPACK may add new routines, but you can always link with the vanilla > Netlib version, and openblas is currently only one release behind. The > LAPACK release notes I've seen aren't very helpful for following that. > The important requirement is fast GEMM from the optimized BLAS. I > thought BLIS just provided the BLAS layer, which is quite stable, isn't > it? I tried a while back to link PaSTiX (a sparse matrix direct solver developed by colleagues of mine), IIRC, against BLIS, and it would miss a couple of functions that Netlib LAPACK provides. >> Packages also often check for specific implementations in >> their configure/CMakeLists.txt rather than just for =E2=80=9CBLAS=E2=80= =9D or =E2=80=9CLAPACK=E2=80=9D. > > It doesn't matter what they're built against when you dynamically load a > compatible version. Right but they do that precisely because all these implementations provide different subsets of the Netlib APIs, AIUI. >> FlexiBLAS, which Eric mentioned, looks interesting because it=E2=80=99s = designed >> specifically for that purpose. Perhaps worth giving it a try. > > I see it works by wrapping everything, which I wanted to avoid. Also > it's GPL, which restricts its use. What's the advantage over just > having implementations which are directly interchangeable at load time? Dunno, I haven=E2=80=99t dig into it. >> Besides, it would be good to have a BLAS/LAPACK policy in Guix. We >> should at least agree (1) on default BLAS/LAPACK implementations, (2) >> possibly on a naming scheme for variants based on a different >> implementation. > > Yes, but the issue is wider than just linear algebra. It seems to > reflect tension between Guix' approach (as I understand it) and the late > binding I expect to use. There are potentially other libraries with > similar micro-architecture-specific issues, and the related one of > profiling/debugging versions. I don't know how much of a real problem > there really is, and it would be good to know if someone has addressed > this. Guix=E2=80=99 approach is to use static binding a lot, and late binding sometimes. For all things plugin-like we use late binding. For shared libraries (not dlopened) we use static binding. Static binding has a cost, as you write, but it gives us control over the environment, and the ability to capture and replicate the software environment. As a user, that=E2=80=99s something I value a lot. I=E2=80=99d also argue that this is something computational scientists shou= ld value: first because results they publish should not depend on the phase of the moon, second because they should be able to provide peers with a self-contained recipe to reproduce them. > Yes, but even with dynamic dispatch you need to account for situations > like we currently have on x86_64 with OB not supporting the latest > micro-architecture, and it only works on x86 with OB. You may also want > to avoid overhead -- see FFTW's advice for packaging. Oh for SIMD > hwcaps... I=E2=80=99m not sure what you mean. That OB does not support the latest micro-architecture is not something the package manager can solve. As for overhead, it should be limited to load time, as illustrated by IFUNC and similar designs. Thanks, Ludo=E2=80=99.