From debbugs-submit-bounces@debbugs.gnu.org Mon Dec 06 07:55:30 2021 Received: (at 52283) by debbugs.gnu.org; 6 Dec 2021 12:55:30 +0000 Received: from localhost ([127.0.0.1]:60754 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1muDWj-0007Tl-UQ for submit@debbugs.gnu.org; Mon, 06 Dec 2021 07:55:30 -0500 Received: from mail-wm1-f48.google.com ([209.85.128.48]:53871) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1muDWe-0007TV-UQ for 52283@debbugs.gnu.org; Mon, 06 Dec 2021 07:55:28 -0500 Received: by mail-wm1-f48.google.com with SMTP id y196so8039154wmc.3 for <52283@debbugs.gnu.org>; Mon, 06 Dec 2021 04:55:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version:content-transfer-encoding; bh=sdNy3KhraPy3awezdLp+n5HWJf+viFJ5WoB8B3Qna2s=; b=WfdMTYXFpd5HO7Yn3UNp1qr6Htl0c0daxhTljTDy/cNpQyJ9Q3Wy2ZsUFzqwHu7r9o Nb6RGi5SOOUgMyJGkAOj6A4nA8BwqWoGhE8SUtVwsr1rvM99Q8dAgTxcQHamztDQM7Ih gapg5cKmyEH8fY/Q1ozGs0TjBTzn3poGmaRyK2tAOL+4S0S5JyiCQy/HWUYwsHBkrMUD kt1fTZY2Aj0lnNBNpJVP/WoNyIJehcteT8dmGM8cSZqe17R8AGfQCpoxpAHM6n3n6u87 fQ4GXJu0aWLOH3uIEqOW2GTHOBUvW/BjkpUqU7GtlzdAts85zoQ4uK7p2uooZR0mUBaa KPMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version:content-transfer-encoding; bh=sdNy3KhraPy3awezdLp+n5HWJf+viFJ5WoB8B3Qna2s=; b=WelX+XvyA+wFCZGDep5/sPnnbz/kVII1dMoTL7gGmtSWfr77S0z6NOojxRL6ST4nm6 dglNkszgkVRYUJqznW3mcMyj2n9FxWB55AaJGV0rlrGggRLhEYB+nk5Mpr5sw8czrZrn osQon60ot9ce471sZdCbwfZkwEhxR7hqV9KxhILBTsu9uj7rgtKND5jxbew/C4MBqqDV wsVhQ2BEDKp5WlapBAmVP/H9QTpuaGw1+6albfZCF5lBfmqGgQ5JHa93CoV43gYcM6jH 89UeIqPjepEyQF9xPKPNGasaELuVjwTimGZqiONydddlBanDPSbdG8PZ/sEJXgABlJkQ wkNw== X-Gm-Message-State: AOAM530rZcArwdDxYBJBDq06xo6/O1uZ57oNF4ITDIm6Y8sLDvtcDLRm YhqOcwhaBXiC2qHRDT1LmR9NgB0/A7I= X-Google-Smtp-Source: ABdhPJzZls2+rhPlVZYK5aR59pP4W23ZgLMUZjl4HcBbSshptJ1bUrj11dZ5R4POCXll6skLXGxWDA== X-Received: by 2002:a1c:f20e:: with SMTP id s14mr39526189wmc.186.1638795318887; Mon, 06 Dec 2021 04:55:18 -0800 (PST) Received: from lili ([2a01:e0a:59b:9120:65d2:2476:f637:db1e]) by smtp.gmail.com with ESMTPSA id u13sm15334047wmq.14.2021.12.06.04.55.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Dec 2021 04:55:18 -0800 (PST) From: zimoun To: Ludovic =?utf-8?Q?Court=C3=A8s?= , Mathieu Othacehe Subject: Re: [bug#52283] [PATCH 00/10] Tuning packages for CPU micro-architectures In-Reply-To: <87zgpeqaq5.fsf_-_@gnu.org> References: <20211204203447.15200-1-ludo@gnu.org> <20211204204924.15581-1-ludo@gnu.org> <87czmb1m8a.fsf_-_@gnu.org> <87zgpeqaq5.fsf_-_@gnu.org> Date: Mon, 06 Dec 2021 13:47:08 +0100 Message-ID: <86zgpdoq7n.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 52283 Cc: 52283@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hi Ludo, Really cool! Thanks! On Mon, 06 Dec 2021 at 11:38, Ludovic Court=C3=A8s wrote: > Mathieu Othacehe skribis: >>> +(define-record-type >>> + (cpu architecture family model flags) >>> + cpu? >>> + (architecture cpu-architecture) ;string, from 'uname' >>> + (family cpu-family) ;integer >>> + (model cpu-model) ;integer >>> + (flags cpu-flags)) ;set of strings >> >> When using the "--tune" transformation option with "native", we can >> expect the current-cpu method to fill the record correctly. >> >> However, when the user is passing a custom cpu name, it might be >> incorrect. I think we should check the user input against a list of >> valid/supported cpu architectures. [...] > Right. I=E2=80=99m a bit torn because I agree with the usability issue a= nd > solution you propose, but at the same time I know that maintaining a > list of existing CPU names will be tedious and it=E2=80=99ll be annoying = for > users if they can=E2=80=99t just specify their CPU name (which they might= want > to do precisely when =E2=80=98--tune=3Dnative=E2=80=99 doesn=E2=80=99t de= termine the right name > because it doesn=E2=80=99t know about it yet.) I have not looked at all the details but this list of existing CPU name is not somehow already maintained, no? --8<---------------cut here---------------start------------->8--- +(define (cpu->gcc-architecture cpu) + "Return the architecture name, suitable for GCC's '-march' flag, that +corresponds to CPU, a record as returned by 'current-cpu'." + (match (cpu-architecture cpu) + ("x86_64" + ;; Transcribed from GCC's 'host_detect_local_cpu' in driver-i386.c. + (or (and (=3D 6 (cpu-family cpu)) ;the "Pentium Pro" fa= mily + (letrec-syntax ((model (syntax-rules (=3D>) + ((_) #f) + ((_ (candidate =3D> integers ...) = rest + ...) + (or (and (=3D (cpu-model cpu) int= egers) + candidate) + ... + (model rest ...)))))) + (model ("bonnel" =3D> #x1c #x26) + ("silvermont" =3D> #x37 #x4a #x4d #x5a #x5d) + ("core2" =3D> #x0f #x17 #x1d) + ("nehalem" =3D> #x1a #x1e #x1f #x2e) + ("westmere" =3D> #x25 #x2c #x2f) + ("sandybridge" =3D> #x2a #x2d) + ("ivybridge" =3D> #x3a #x3e) + ("haswell" =3D> #x3c #x3f #x45 #x46) + ("broadwell" =3D> #x3d #x47 #x4f #x56) + ("skylake" =3D> #x4e #x5e #x8e #x9e) + ("skylake-avx512" =3D> #x55) ;TODO: cascadelake + ("knl" =3D> #x57) + ("cannonlake" =3D> #x66) + ("knm" =3D> #x85)))) --8<---------------cut here---------------end--------------->8--- >> Maybe the (guix cpu) and (gnu platform) modules should be merged somehow >> to define the supported CPU micro-architectures: >> >> (define armv7-linux >> (platform >> (target "arm-linux-gnueabihf") >> (system "armhf-linux") >> (linux-architecture "arm") >> (supported-march '("armv7" "armv7-a" "armv7ve")) >> >> we could then use those platform records in the (gnu ci) module to build >> packages against all the supported micro architectures and remove the >> "%x86-64-micro-architecture" variable you propose to introduce there. > > Hmm yeah, but it should be (guix platforms) then=E2=80=A6 > > Maybe that=E2=80=99s a broader refactoring we can keep for later? I agre= e it > would be logical but I=E2=80=99m not sure how to nicely factorize things. Yeah, I am always annoyed for the arguments of =E2=80=99-s=E2=80=99 vs =E2= =80=99-t=E2=80=99, aside the ugly backtrace. :-) The same (as we do elsewhere) is to somehow have options =E2=80=99--list-systems=E2=80=99 and =E2=80=99--list-targets=E2=80= =99 and handle incorrect values; similar to =E2=80=9Cguix lint=E2=80=9D for checkers or =E2=80=9Cgui= x graph=E2=80=9D for types or backends, etc. With potentially some hints. :-) I also agree that=E2=80=99s unrelated to the current series. :-) This refactoring could happen later, IMHO. Cheers, simon