From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Love Subject: Re: OpenBLAS and performance Date: Fri, 22 Dec 2017 12:45:01 +0000 Message-ID: <87vagz0w4y.fsf@albion.it.manchester.ac.uk> References: <20171219104956.GB806@thebird.nl> <87tvwl7h4w.fsf@albion.it.manchester.ac.uk> <87ind05dwm.fsf@gnu.org> 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]:59075) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eSMhJ-0008AM-PZ for guix-devel@gnu.org; Fri, 22 Dec 2017 07:45:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eSMhG-0007Gt-Jh for guix-devel@gnu.org; Fri, 22 Dec 2017 07:45:09 -0500 Received: from tranquility.mcc.ac.uk ([130.88.200.145]:59854) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eSMhG-0007EE-Cw for guix-devel@gnu.org; Fri, 22 Dec 2017 07:45:06 -0500 In-Reply-To: <87ind05dwm.fsf@gnu.org> ("Ludovic \=\?iso-8859-1\?Q\?Court\=E8s\?\= \=\?iso-8859-1\?Q\?\=22's\?\= message of "Thu, 21 Dec 2017 15:55:21 +0100") 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: Ludovic =?iso-8859-1?Q?Court=E8s?= Cc: Guix-devel , Eric Bavier , Federico Beffa 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 approa= ch 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. > Unfortunately my understanding is that implementations aren=E2=80=99t ent= irely > 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? > 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. (You'd hope a build system would be able to find arbitrary BLAS but I'm too familiar with cmake pain.) The openblas compatibility hack basically just worked on an RHEL6 cluster when I maintained it. > FlexiBLAS, which Eric mentioned, looks interesting because it=E2=80=99s d= esigned > 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? > 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. It's a reason I'm currently not convinced about the trades-off with Guix, and don't go along with the "reproducibility" mantra. Obviously I'm not writing Guix off, though, and I hope the discussion is useful. > For #1 we should probably favor implementations that support run-time > implementation selection such as OpenBLAS (or the coming BLIS release). > > Thoughts? > > Ludo=E2=80=99. 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...