From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Vong Subject: Re: Pre-built binaries vs. performance Date: Thu, 01 Feb 2018 02:21:11 +0800 Message-ID: <87607hq488.fsf@gmail.com> References: <87y3ketaf6.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]:56667) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1egx0h-0000JL-OD for guix-devel@gnu.org; Wed, 31 Jan 2018 13:21:28 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1egx0c-0004i8-Q4 for guix-devel@gnu.org; Wed, 31 Jan 2018 13:21:27 -0500 Received: from mail-pf0-x244.google.com ([2607:f8b0:400e:c00::244]:38548) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1egx0c-0004hR-K3 for guix-devel@gnu.org; Wed, 31 Jan 2018 13:21:22 -0500 Received: by mail-pf0-x244.google.com with SMTP id k19so13480698pfj.5 for ; Wed, 31 Jan 2018 10:21:22 -0800 (PST) In-Reply-To: <87y3ketaf6.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Wed, 31 Jan 2018 14:39:09 +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 =?utf-8?Q?Court=C3=A8s?= Cc: guix-devel ludovic.courtes@inria.fr (Ludovic Court=C3=A8s) writes: > Hello Guix! > > This post is a followup to our previous discussions on how to handle > architecture-specific optimizations: > > https://guix-hpc.bordeaux.inria.fr/blog/2018/01/pre-built-binaries-vs-p= erformance/ > > Comments welcome! > > Ludo=E2=80=99. I encountered this problem several years ago when packaging for Debian. The program (a single binary) could be compiled with 3 different sets of options: generic, AVX or AVX2. The goal was to package it so that users didn't have to specify which version to install. The hack I came up with was to compile all 3 variants and wrote a shell wrapper to run self-tests for all 3 variants. If the self-test for the AVX2 variant works, then pick it. If not, try AVX. If not, fall back to generic. This way was quite crude. Now I think we can make use of /proc/cpuinfo. Will this method work? An obvious disadvantage is that more disk space will be needed.