From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id CB3BF138334 for ; Thu, 30 May 2019 04:06:54 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 18DABE08D1; Thu, 30 May 2019 04:06:50 +0000 (UTC) Received: from smtp.gentoo.org (dev.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id C2BBDE08BB for ; Thu, 30 May 2019 04:06:48 +0000 (UTC) Received: from muon (vm4.gentoo.osuosl.org [140.211.166.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: heroxbd) by smtp.gentoo.org (Postfix) with ESMTPSA id F3816345238 for ; Thu, 30 May 2019 04:06:46 +0000 (UTC) Received: from [2001:470:4c22:ae86:babe:150:0:1] (port=51830 helo=robot) by muon with esmtp (Exim 4.89) (envelope-from ) id 1hWCKx-0003WN-VQ for gentoo-dev@lists.gentoo.org; Thu, 30 May 2019 04:06:44 +0000 From: Benda Xu To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] RFC: BLAS and LAPACK runtime switching References: <2d3636f5bd6a738f30a4ad2e697b1ddb@debian.org> <9d42e0cc818985fcc8141743bbd840b85a58557e.camel@gentoo.org> <87lfypuy7v.fsf@proton.d.airelinux.org> Date: Thu, 30 May 2019 12:06:42 +0800 In-Reply-To: (David Seifert's message of "Wed, 29 May 2019 16:39:53 +0200") Message-ID: <871s0gegbx.fsf@gentoo.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: text/plain X-Archives-Salt: 99a981e3-8115-4fcb-afd7-9c1f539f6ede X-Archives-Hash: 20d473a5467f1ffe48907b0e2244af81 Hi David, David Seifert writes: >> > An actual ABI compliance test, e.g. done using abi-compliance- >> > checker would be more interesting. >> >> As said above, the symbols don't need to be 1-1 copy of each other. >> Any library which is a superset of the reference one will work. > > Again, I'm willing to accept this under a USE="lapack_targets_virtual" > configuration, I hear you, and I was with the same opinion, too. Nevertheless, if a runtime switch works, it is simpler than USE_EXPAND. We already have a couple of them, PYTHON_TARGET, RUBY_TARGET, etc. I don't want to add more to this list unless absolutely necessary. Alternatively, it could be exclusive USE flags instead of USE_EXPAND. That's possible and we need to add a lot of USE flags, OpenBLAS, blis, reference, altas, nvBLAS, etc. I don't think it a clean solution. > but wholesale editing of DT_NEEDED entries is definitely too scary and > too invasive for most non-sci/hpc users of Gentoo. Sorry if I confused you. There is no hack of DT_NEEDED involved. An application is compiled against the reference, then it is pointed by LDPATH and ld.so.conf to a drop-in replacement library, and it profits. That's not more than upgrading a dynamic library. The scheme was shown to work with gcc runtime, libstdc++, and opengl, in Gentoo. > Again, for 99% of users, OpenBLAS will be the right trade-off between > performance and customizability. Every recompilation of libreoffice or > chromium will devour more CPU cycles than switching between USE-flag > implementations. I understand your point. Let me elaborate: 1. OpenBLAS has quite a bit of hand-tuned assembly, it is not very portable. Special care is need to manage the default BLAS on profiles, like ppc64, arm64, arm, riscv, etc. 2. All the Gentoo users care about optimization. And there are non-science applications that call linear algebra routines. 3. Maintaining different BLAS frameworks in repo/gentoo.git and proj/sci.git wastes everybody's time, and causes endless confusion to users. That offsets the time saved to make OpenBLAS the global default. Therefore, from the users' point of view, I still think runtime switching makes more sense. Yours, Benda