From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id EMEOKskJrmE4iQAAgWs5BA (envelope-from ) for ; Mon, 06 Dec 2021 14:02:01 +0100 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id CG3TJckJrmFsQgAAB5/wlQ (envelope-from ) for ; Mon, 06 Dec 2021 13:02:01 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 56B802C9D8 for ; Mon, 6 Dec 2021 14:02:01 +0100 (CET) Received: from localhost ([::1]:36736 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1muDd2-0007Cz-2J for larch@yhetil.org; Mon, 06 Dec 2021 08:02:00 -0500 Received: from eggs.gnu.org ([209.51.188.92]:54010) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1muDXF-0006Vt-TR for guix-patches@gnu.org; Mon, 06 Dec 2021 07:56:02 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:49212) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1muDXF-0002Av-LG for guix-patches@gnu.org; Mon, 06 Dec 2021 07:56:01 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1muDXF-0007Uo-IN for guix-patches@gnu.org; Mon, 06 Dec 2021 07:56:01 -0500 X-Loop: help-debbugs@gnu.org Subject: [bug#52283] [PATCH 00/10] Tuning packages for CPU micro-architectures Resent-From: zimoun Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Mon, 06 Dec 2021 12:56:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 52283 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Ludovic =?UTF-8?Q?Court=C3=A8s?= , Mathieu Othacehe Cc: 52283@debbugs.gnu.org Received: via spool by 52283-submit@debbugs.gnu.org id=B52283.163879533028757 (code B ref 52283); Mon, 06 Dec 2021 12:56:01 +0000 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 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-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: "Guix-patches" X-Migadu-Flow: FLOW_IN X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1638795721; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:resent-cc: resent-from:resent-sender:resent-message-id:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=sdNy3KhraPy3awezdLp+n5HWJf+viFJ5WoB8B3Qna2s=; b=tHlpSC8aCKG1QRAxVMl+xyByK+nDVVJIC9+ksx7OSHdK14wm6bbBp2pymASLqea8ZpmOrb mn2BOmfDQmsfFOFIfPp63vEoCTupxuzbx1TBpXaxbbeRHIP6czz4FRdnWZ4y+Y3P7PF5xd oQVbmrOotxDr34yxlvjP/JkROrs/+jreicF195s38fjCyh9gB8pzYS0cGKpkznjSEiduH9 IMYs/dZao7dsTLiwxXTTj4f3MmgwtAGZu6ve54ZZB66/5+Ln/TEOmG1zKYUivdSleX13po cujLxDd56w1Xy6zm9ZKNX6qnMx1kAWpjvIEK+7aCTw24pbZTUHQKpJRuJJtznw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1638795721; a=rsa-sha256; cv=none; b=qv1eoy1/LwZpB5eBPCpuUdpVA7OCoCrNuL8BEd/Kr+wyQ5tfrcZOv0soT0p8guyqfAqDYE Jie19n4OKXkFjVaq4sx6Gs103eMJMTSGpxbbM5b9FQNVZLxBiU4nG8wuj4WVyIQKSUEj4w MRpHPBdjbY46iDpMPtc4HtfmUrfWFb78hmVOOodOHdMGMmcTDPiQLP5rUqD5Y1kYuq9AJS bEyUJ3ffFpyi+3p8HrycEiW37RSf02wsNTfeu/8z+6nWeDXFjxEqLkUWohSNDWYKysSKPI IENTKWR4msOfdKkAm5pxu63gQVd8Wvjg/6lqHYIvbqexcSF1hLBD0UVY1xADow== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20210112 header.b=WfdMTYXF; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -0.34 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20210112 header.b=WfdMTYXF; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 56B802C9D8 X-Spam-Score: -0.34 X-Migadu-Scanner: scn0.migadu.com X-TUID: PEuTMvLn0WvV 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