From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 18 11:03:16 2021 Received: (at submit) by debbugs.gnu.org; 18 Mar 2021 15:03:16 +0000 Received: from localhost ([127.0.0.1]:47690 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lMuB3-0000Jo-V6 for submit@debbugs.gnu.org; Thu, 18 Mar 2021 11:03:16 -0400 Received: from lists.gnu.org ([209.51.188.17]:56674) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lMuB2-0000Jg-1F for submit@debbugs.gnu.org; Thu, 18 Mar 2021 11:03:08 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:37160) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lMuB0-0006Zv-Co for guix-patches@gnu.org; Thu, 18 Mar 2021 11:03:07 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:56760) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lMuAu-0006lT-9N; Thu, 18 Mar 2021 11:03:02 -0400 Received: from [2a01:e0a:1d:7270:af76:b9b:ca24:c465] (port=53470 helo=gnu.org) by fencepost.gnu.org with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lMuAt-0006u1-QE; Thu, 18 Mar 2021 11:03:00 -0400 From: =?UTF-8?q?Ludovic=20Court=C3=A8s?= To: guix-patches@gnu.org Subject: [PATCH] gnu: metis: Use 64-bit floating pointer numbers on 64-bit architectures. Date: Thu, 18 Mar 2021 16:02:46 +0100 Message-Id: <20210318150246.7220-1-ludo@gnu.org> X-Mailer: git-send-email 2.30.2 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: submit Cc: Emmanuel Agullo , =?UTF-8?q?Ludovic=20Court=C3=A8s?= , Eric Bavier , Paul Garlick 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 (-) From: Ludovic Courtès * gnu/packages/maths.scm (metis)[arguments]: Add #:modules and #:phases. --- gnu/packages/maths.scm | 23 +++++++++++++++++++++-- 1 file changed, 21 insertions(+), 2 deletions(-) Hi! Metis defaults to 32-bit floating point numbers. However, on 64-bit platforms, users probably expect 64-bit floating point numbers, hence this patch. We could make it configurable through different variants or via package parameters when they’re available, but I wonder about the usefulness of a variant that uses 32-bit floats on 64-bit architectures. Can we keep just this one variant? Thanks, Ludo’. diff --git a/gnu/packages/maths.scm b/gnu/packages/maths.scm index 565f109f47..4cd9112be9 100644 --- a/gnu/packages/maths.scm +++ b/gnu/packages/maths.scm @@ -12,7 +12,7 @@ ;;; Copyright © 2015 Fabian Harfert ;;; Copyright © 2016 Roel Janssen ;;; Copyright © 2016, 2018, 2020 Kei Kebreau -;;; Copyright © 2016, 2017, 2018, 2019, 2020 Ludovic Courtès +;;; Copyright © 2016, 2017, 2018, 2019, 2020, 2021 Ludovic Courtès ;;; Copyright © 2016 Leo Famulari ;;; Copyright © 2016, 2017 Thomas Danckaert ;;; Copyright © 2017, 2018, 2019, 2020 Paul Garlick @@ -3312,7 +3312,26 @@ YACC = bison -pscotchyy -y -b y `(#:tests? #f ;no tests #:configure-flags `("-DSHARED=ON" ,(string-append "-DGKLIB_PATH=" (getcwd) - "/metis-" ,version "/GKlib")))) + "/metis-" ,version "/GKlib")) + + #:modules ((system base target) + (guix build cmake-build-system) + (guix build utils)) + #:phases (modify-phases %standard-phases + (add-after 'unpack 'set-real-type-width + (lambda* (#:key build target #:allow-other-keys) + ;; Enable 64-bit floating point numbers on 64-bit + ;; architectures. Leave the default 32-bit width on + ;; other architectures. + (let ((word-size + (with-target (or target build %host-type) + (lambda () + (target-word-size))))) + (when (= 8 word-size) + (display "setting REALTYPEWIDTH to 64...\n") + (substitute* "include/metis.h" + (("define REALTYPEWIDTH.*$") + "define REALTYPEWIDTH 64\n"))))))))) (home-page "http://glaros.dtc.umn.edu/gkhome/metis/metis/overview") (synopsis "Graph partitioning and fill-reducing matrix ordering library") (description -- 2.30.2 From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 18 11:28:19 2021 Received: (at submit) by debbugs.gnu.org; 18 Mar 2021 15:28:19 +0000 Received: from localhost ([127.0.0.1]:47753 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lMuZH-0000ye-Ae for submit@debbugs.gnu.org; Thu, 18 Mar 2021 11:28:19 -0400 Received: from lists.gnu.org ([209.51.188.17]:42866) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lMuZF-0000yV-Ec for submit@debbugs.gnu.org; Thu, 18 Mar 2021 11:28:09 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:43586) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lMuZF-0000om-8c for guix-patches@gnu.org; Thu, 18 Mar 2021 11:28:09 -0400 Received: from mail2-relais-roc.national.inria.fr ([192.134.164.83]:53623) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lMuZC-00061K-Qn; Thu, 18 Mar 2021 11:28:09 -0400 IronPort-HdrOrdr: =?us-ascii?q?A9a23=3ARWhvLqOg33UIUsBcT5n155DYdL4zR+YMi2QD?= =?us-ascii?q?/UoZc3BoW+afkN2jm+le6AT9jywfVGpltdeLPqSBRn20z+8R3aA6O7C+UA76/F?= =?us-ascii?q?a5NY0K1/qB/xTMEzDzn9Q36Y5OaK57YeebMXFbioLA7BC8A5IcxrC8npyAocf7?= =?us-ascii?q?4zNTQRpxa6dmhj0JaTqzNkFtXgFJCd4YOfOnifZvnDardXQJYsnTPBBsY8H5q9?= =?us-ascii?q?LGj57gaxIdbiRH1CC1kTiq5LTmeiL54j4iUihCybpn0W/Jnx2R3NTbj9iHywTR?= =?us-ascii?q?32KW0pJOmNGJ8KokOOWwjKEuRwnEu0KNbIRlV6bqhkFTnMifrHAwkNfNpB88P8?= =?us-ascii?q?N8r1PpF1vFxSfQ5w=3D=3D?= X-IronPort-AV: E=Sophos;i="5.81,259,1610406000"; d="scan'208";a="498716606" X-MGA-submission: =?us-ascii?q?MDENWvSUVN/9OUpG2PBGncXb516Iv/bjvrLj5B?= =?us-ascii?q?j2wCpBW5/fDAWWOP1NYVyuvE8r7mQV+8rlxy99uAOsQihmAOV4RMEfL2?= =?us-ascii?q?wq7FATGbNHj7rLrIjtF6bYWO/Vj0iGrZVmumyU0YZs3Tcm79saX6s3L6?= =?us-ascii?q?Oj77j/E3jllYab3emTBN0pug=3D=3D?= Received: from zcs-store4.inria.fr ([128.93.142.31]) by mail2-relais-roc.national.inria.fr with ESMTP; 18 Mar 2021 16:27:22 +0100 Date: Thu, 18 Mar 2021 16:27:22 +0100 (CET) From: Emmanuel Agullo To: Ludovic =?iso-8859-1?Q?Court=E8s?= Message-ID: <79577287.1930022.1616081242591.JavaMail.zimbra@inria.fr> In-Reply-To: <20210318150246.7220-1-ludo@gnu.org> References: <20210318150246.7220-1-ludo@gnu.org> Subject: Re: [PATCH] gnu: metis: Use 64-bit floating pointer numbers on 64-bit architectures. MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [5.49.130.168] X-Mailer: Zimbra 8.8.15_GA_3996 (ZimbraWebClient - FF84 (Linux)/8.8.15_GA_4007) Thread-Topic: metis: Use 64-bit floating pointer numbers on 64-bit architectures. Thread-Index: MxmO6tHuo/RN2LmBdwEKDA94pVt22Q== Received-SPF: pass client-ip=192.134.164.83; envelope-from=emmanuel.agullo@inria.fr; helo=mail2-relais-roc.national.inria.fr X-Spam_score_int: -41 X-Spam_score: -4.2 X-Spam_bar: ---- X-Spam_report: (-4.2 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit Cc: Ludovic Courtes , Eric Bavier , Paul Garlick , guix-patches@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: -0.0 (/) Hello Ludo, hello everybody, Thank you very much for this patch and discussion. In numerical linear algebra in particular and hpc in general, the trend is more and more to use reduced=20 floating point arithmetic whenever possible (for memory=20 footprint, communication volume and possibly computational=20 time). I have no experience with using floating point=20 numbers in partitioners such as metis. But I strongly=20 suspect that a flexible usage will be requested (the=20 same way it is often requested for integers). All in all,=20 I would say that the number of bits for the architecture,=20 the floating point numbers and the integers shall not=20 (a priori) be related. In particular, I would say, in general,=20 if a (high-quality) library (such as metis) exposes multiple=20 choices, there are chances that users may want to choose between them (for good reasons). In the long run, it would be nice to have a naming convention all over guix to make clear (and explicit) for libraries that expose it which floating point and integer arithmetic is being used. There can hardly be a general rule (as some codes may even decide to expose, say, part of the integers in 32 bits and another part in 64 bits), but it would already be a great step to have a convention for the "main" integer choice and "main" floating-point choice. Something like mypackage_i32_r64 (if there is a general convention (beyond guix) to follow, even better). [It may even be great to use two versions of the same package to facilitate mixed arithmetic,=20 but we can certainly pospone that discussion as it would certainly open two many issues for now]. In the short run, if there can be only one, I let metis users playing with floating point numbers comment on which one shall it be. Hope this helps. Thank you again. Best regards, Manu ----- Mail original ----- > De: "Ludovic Court=C3=A8s" > =C3=80: guix-patches@gnu.org > Cc: "Eric Bavier" , "Emmanuel Agullo" , "Paul Garlick" > , "Ludovic Courtes" > Envoy=C3=A9: Jeudi 18 Mars 2021 16:02:46 > Objet: [PATCH] gnu: metis: Use 64-bit floating pointer numbers on 64-bit = architectures. > From: Ludovic Court=C3=A8s >=20 > * gnu/packages/maths.scm (metis)[arguments]: Add #:modules and #:phases. > --- > gnu/packages/maths.scm | 23 +++++++++++++++++++++-- > 1 file changed, 21 insertions(+), 2 deletions(-) >=20 > Hi! >=20 > Metis defaults to 32-bit floating point numbers. However, on 64-bit > platforms, users probably expect 64-bit floating point numbers, hence > this patch. >=20 > We could make it configurable through different variants or via package > parameters when they=E2=80=99re available, but I wonder about the usefuln= ess of > a variant that uses 32-bit floats on 64-bit architectures. Can we keep > just this one variant? >=20 > Thanks, > Ludo=E2=80=99. >=20 > diff --git a/gnu/packages/maths.scm b/gnu/packages/maths.scm > index 565f109f47..4cd9112be9 100644 > --- a/gnu/packages/maths.scm > +++ b/gnu/packages/maths.scm > @@ -12,7 +12,7 @@ > ;;; Copyright =C2=A9 2015 Fabian Harfert > ;;; Copyright =C2=A9 2016 Roel Janssen > ;;; Copyright =C2=A9 2016, 2018, 2020 Kei Kebreau > -;;; Copyright =C2=A9 2016, 2017, 2018, 2019, 2020 Ludovic Court=C3=A8s <= ludo@gnu.org> > +;;; Copyright =C2=A9 2016, 2017, 2018, 2019, 2020, 2021 Ludovic Court=C3= =A8s > > ;;; Copyright =C2=A9 2016 Leo Famulari > ;;; Copyright =C2=A9 2016, 2017 Thomas Danckaert > ;;; Copyright =C2=A9 2017, 2018, 2019, 2020 Paul Garlick > > @@ -3312,7 +3312,26 @@ YACC =3D bison -pscotchyy -y -b y > `(#:tests? #f ;no tests > #:configure-flags `("-DSHARED=3DON" > ,(string-append "-DGKLIB_PATH=3D" (getcwd) > - "/metis-" ,version "/GKlib"))= )) > + "/metis-" ,version "/GKlib")) > + > + #:modules ((system base target) > + (guix build cmake-build-system) > + (guix build utils)) > + #:phases (modify-phases %standard-phases > + (add-after 'unpack 'set-real-type-width > + (lambda* (#:key build target #:allow-other-keys) > + ;; Enable 64-bit floating point numbers on 64-bit > + ;; architectures. Leave the default 32-bit width = on > + ;; other architectures. > + (let ((word-size > + (with-target (or target build %host-type) > + (lambda () > + (target-word-size))))) > + (when (=3D 8 word-size) > + (display "setting REALTYPEWIDTH to 64...\n") > + (substitute* "include/metis.h" > + (("define REALTYPEWIDTH.*$") > + "define REALTYPEWIDTH 64\n"))))))))) > (home-page "http://glaros.dtc.umn.edu/gkhome/metis/metis/overview") > (synopsis "Graph partitioning and fill-reducing matrix ordering libra= ry") > (description > -- > 2.30.2 From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 18 14:42:16 2021 Received: (at submit) by debbugs.gnu.org; 18 Mar 2021 18:42:16 +0000 Received: from localhost ([127.0.0.1]:48048 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lMxb0-0001u3-5T for submit@debbugs.gnu.org; Thu, 18 Mar 2021 14:42:16 -0400 Received: from lists.gnu.org ([209.51.188.17]:42240) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lMxay-0001tp-9J for submit@debbugs.gnu.org; Thu, 18 Mar 2021 14:42:08 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:53510) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lMxay-0000mC-0Z for guix-patches@gnu.org; Thu, 18 Mar 2021 14:42:08 -0400 Received: from smtp.hosts.co.uk ([85.233.160.19]:14741) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lMxav-0004pz-5X; Thu, 18 Mar 2021 14:42:07 -0400 Received: from maikeh336.claranet.co.uk ([79.123.23.187] helo=pancake.local) by smtp.hosts.co.uk with esmtpsa (TLS1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim) (envelope-from ) id 1lMxal-0009tq-D6; Thu, 18 Mar 2021 18:41:55 +0000 Message-ID: <48a8a7c4dbe90415468d8db64cdfd82be52aeb4e.camel@tourbillion-technology.com> Subject: Re: [PATCH] gnu: metis: Use 64-bit floating pointer numbers on 64-bit architectures. From: Paul Garlick To: Ludovic =?ISO-8859-1?Q?Court=E8s?= , guix-patches@gnu.org Date: Thu, 18 Mar 2021 18:41:53 +0000 In-Reply-To: <20210318150246.7220-1-ludo@gnu.org> References: <20210318150246.7220-1-ludo@gnu.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.2 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Received-SPF: none client-ip=85.233.160.19; envelope-from=pgarlick@tourbillion-technology.com; helo=smtp.hosts.co.uk X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_NONE=0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: submit Cc: Emmanuel Agullo , Ludovic =?ISO-8859-1?Q?Court=E8s?= , Eric Bavier 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, I think it is a good idea to allow for different variants, even on 64- bit architectures. In one direction there is a performance advantage using 32-bit floats. In the other direction accuracy improves using the 64-bit data type. There is a similar situation with the scotch library. The scotch32 package variant is preferable, even on 64-bit systems, except for the case of very large models. Best regards, Paul. On Thu, 2021-03-18 at 16:02 +0100, Ludovic Courtès wrote: > From: Ludovic Courtès > > * gnu/packages/maths.scm (metis)[arguments]: Add #:modules and #:phases. > --- > gnu/packages/maths.scm | 23 +++++++++++++++++++++-- > 1 file changed, 21 insertions(+), 2 deletions(-) > > Hi! > > Metis defaults to 32-bit floating point numbers. However, on 64-bit > platforms, users probably expect 64-bit floating point numbers, hence > this patch. > > We could make it configurable through different variants or via package > parameters when they’re available, but I wonder about the usefulness of > a variant that uses 32-bit floats on 64-bit architectures. Can we keep > just this one variant? > > Thanks, > Ludo’. > > diff --git a/gnu/packages/maths.scm b/gnu/packages/maths.scm > index 565f109f47..4cd9112be9 100644 > --- a/gnu/packages/maths.scm > +++ b/gnu/packages/maths.scm > @@ -12,7 +12,7 @@ > ;;; Copyright © 2015 Fabian Harfert > ;;; Copyright © 2016 Roel Janssen > ;;; Copyright © 2016, 2018, 2020 Kei Kebreau > -;;; Copyright © 2016, 2017, 2018, 2019, 2020 Ludovic Courtès > +;;; Copyright © 2016, 2017, 2018, 2019, 2020, 2021 Ludovic Courtès > ;;; Copyright © 2016 Leo Famulari > ;;; Copyright © 2016, 2017 Thomas Danckaert > ;;; Copyright © 2017, 2018, 2019, 2020 Paul Garlick > @@ -3312,7 +3312,26 @@ YACC = bison -pscotchyy -y -b y > `(#:tests? #f ;no tests > #:configure-flags `("-DSHARED=ON" > ,(string-append "-DGKLIB_PATH=" (getcwd) > - "/metis-" ,version "/GKlib")))) > + "/metis-" ,version "/GKlib")) > + > + #:modules ((system base target) > + (guix build cmake-build-system) > + (guix build utils)) > + #:phases (modify-phases %standard-phases > + (add-after 'unpack 'set-real-type-width > + (lambda* (#:key build target #:allow-other-keys) > + ;; Enable 64-bit floating point numbers on 64-bit > + ;; architectures. Leave the default 32-bit width on > + ;; other architectures. > + (let ((word-size > + (with-target (or target build %host-type) > + (lambda () > + (target-word-size))))) > + (when (= 8 word-size) > + (display "setting REALTYPEWIDTH to 64...\n") > + (substitute* "include/metis.h" > + (("define REALTYPEWIDTH.*$") > + "define REALTYPEWIDTH 64\n"))))))))) > (home-page "http://glaros.dtc.umn.edu/gkhome/metis/metis/overview") > (synopsis "Graph partitioning and fill-reducing matrix ordering library") > (description > From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 18 17:48:51 2021 Received: (at 47237) by debbugs.gnu.org; 18 Mar 2021 21:48:51 +0000 Received: from localhost ([127.0.0.1]:48238 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lN0Ve-0002Kv-Or for submit@debbugs.gnu.org; Thu, 18 Mar 2021 17:48:50 -0400 Received: from mail-wr1-f44.google.com ([209.85.221.44]:34764) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lN0Vd-0002Ki-05 for 47237@debbugs.gnu.org; Thu, 18 Mar 2021 17:48:49 -0400 Received: by mail-wr1-f44.google.com with SMTP id j7so7091462wrd.1 for <47237@debbugs.gnu.org>; Thu, 18 Mar 2021 14:48:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version; bh=u9NPXg7R0JxGT3qOkfE09DB4JiL7OZ+uRIBMMB5NeqI=; b=DsS88tnsU//ZxclIXe+lp/CWVUZ4Ii/DCCmNVT5dxcWat+PmKcNmZ8lWubryorhfOG SAdV1ML9VtYH/73VPi6R4/LkHENwTkoUaWMExtxPsfyT2UOh6ycZJbr1HvrPTGO6iruV +BrS4j/kR/I7h5eo1NA6rPBxim3JJXdAjsY5IdxVrPPAXKeccXjlb2CHEjAMy5FREIUQ VnLeHpXECXXlNUs4wBsKllLudkfAvq1lGOZ81LY8+kGPJzeLehcyA2n/fQR8SErcO7xQ 2ryCmgFf3sCz5X65IrvXOFPRxLcKAKh9UVNNtgEmsSNpGsI0Dt280zSr/D7mcTbeo8if 3VRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=u9NPXg7R0JxGT3qOkfE09DB4JiL7OZ+uRIBMMB5NeqI=; b=k1BjvjlonnChXSsT8t3Klw4cSaNg5VhhUjBT8BQuj+n2jmA4Cl/8yu+0C0xzvoYBFI c4tFIzDyHSnuGUBzZAy+CGd2bJWBRJZVQXfP+6MLu0dgQg/vGiatXt+pwwCiRhdLH4ke 3vMoWJ8gmZk0G4jdmUBlNk0df9N5UcmtlQChyXBACowoKfKZmMFqWXG0wlRIq64bZmcM dMelojtJUAai5nqNZH6szJFlMTHBPR0q3vBJ9q8OkBMtLq1ReQ5udvBU8DiazNHzBaYQ Tkh0nJk9HUN6Fw/zDFxAg0TmYdNxsKV7sDH2Hi89p8OjFbDgtV78iLzsvjft6RrpS6kW navQ== X-Gm-Message-State: AOAM533d8sHdWUJBbEV/IHPOO8xr0A82Xei2oHRD9NUySsNwjaGYu5RP LDe81R736WyBQzTP5aGUR+yWYc1B/ow= X-Google-Smtp-Source: ABdhPJzi691JF8LzwyfcjbybNwfn0EINbKoWpto6/aQB60b0+zdSzDbZ3jBVwipp31IJjZP6lgKPkA== X-Received: by 2002:adf:8151:: with SMTP id 75mr1294194wrm.152.1616104123117; Thu, 18 Mar 2021 14:48:43 -0700 (PDT) Received: from lili ([2a01:e0a:59b:9120:65d2:2476:f637:db1e]) by smtp.gmail.com with ESMTPSA id z2sm4492496wrv.47.2021.03.18.14.48.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 18 Mar 2021 14:48:41 -0700 (PDT) From: zimoun To: Emmanuel Agullo , Ludovic =?utf-8?Q?Court?= =?utf-8?Q?=C3=A8s?= Subject: Re: [bug#47237] [PATCH] gnu: metis: Use 64-bit floating pointer numbers on 64-bit architectures. In-Reply-To: <79577287.1930022.1616081242591.JavaMail.zimbra@inria.fr> References: <20210318150246.7220-1-ludo@gnu.org> <79577287.1930022.1616081242591.JavaMail.zimbra@inria.fr> Date: Thu, 18 Mar 2021 22:48:03 +0100 Message-ID: <86v99ot9po.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 47237 Cc: ludovic.courtes@inria.fr, bavier@member.fsf.org, pgarlick@tourbillion-technology.com, 47237@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, On Thu, 18 Mar 2021 at 16:27, Emmanuel Agullo wrote: > In numerical linear algebra in particular and hpc in > general, the trend is more and more to use reduced > floating point arithmetic whenever possible (for memory > footprint, communication volume and possibly computational > time). I have no experience with using floating point > numbers in partitioners such as metis. But I strongly [...] > choice. Something like mypackage_i32_r64 (if there > is a general convention (beyond guix) to follow, > even better). [It may even be great to use two versions > of the same package to facilitate mixed arithmetic, > but we can certainly pospone that discussion as it > would certainly open two many issues for now]. I am probably out-of-scope, and it does probably not make sense for partitioners as Metis, how are considered mixed precision solvers? i.e., computing some part using 64 bits floating points and other part using 32 bits. (My memory is not clear but I remember reading couple of weeks ago an acceleration with 3 levels of float-pointing precision.) In the i32_r64 example of convention, what should be considered as rXY? The final accuracy, whatever the internals? Are these mixed precision solvers used and in the trend? Well, I do not know if these questions make sense. Cheers, simon From debbugs-submit-bounces@debbugs.gnu.org Fri Mar 19 05:37:48 2021 Received: (at submit) by debbugs.gnu.org; 19 Mar 2021 09:37:49 +0000 Received: from localhost ([127.0.0.1]:48828 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lNBZk-0003QT-HT for submit@debbugs.gnu.org; Fri, 19 Mar 2021 05:37:48 -0400 Received: from lists.gnu.org ([209.51.188.17]:40688) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lNBZi-0003QL-IQ for submit@debbugs.gnu.org; Fri, 19 Mar 2021 05:37:47 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:39790) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lNBZY-0001m4-Bo for guix-patches@gnu.org; Fri, 19 Mar 2021 05:37:43 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:49307) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lNBZV-0004eg-MD; Fri, 19 Mar 2021 05:37:34 -0400 Received: from [2a01:e0a:1d:7270:af76:b9b:ca24:c465] (port=57450 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lNBZV-0007aV-1I; Fri, 19 Mar 2021 05:37:33 -0400 From: =?utf-8?Q?Ludovic_Court=C3=A8s?= To: Paul Garlick Subject: Re: [PATCH] gnu: metis: Use 64-bit floating pointer numbers on 64-bit architectures. References: <20210318150246.7220-1-ludo@gnu.org> <48a8a7c4dbe90415468d8db64cdfd82be52aeb4e.camel@tourbillion-technology.com> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 29 =?utf-8?Q?Vent=C3=B4se?= an 229 de la =?utf-8?Q?R?= =?utf-8?Q?=C3=A9volution?= X-PGP-Key-ID: 0x090B11993D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-pc-linux-gnu Date: Fri, 19 Mar 2021 10:37:31 +0100 In-Reply-To: <48a8a7c4dbe90415468d8db64cdfd82be52aeb4e.camel@tourbillion-technology.com> (Paul Garlick's message of "Thu, 18 Mar 2021 18:41:53 +0000") Message-ID: <87k0q3iiw4.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: submit Cc: Emmanuel Agullo , Eric Bavier , guix-patches@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: -3.3 (---) Hi Paul and all, Paul Garlick skribis: > I think it is a good idea to allow for different variants, even on 64- > bit architectures. > > In one direction there is a performance advantage using 32-bit floats.=20 > In the other direction accuracy improves using the 64-bit data type. True. That concurs with what Emmanuel explains. > There is a similar situation with the scotch library. The scotch32 > package variant is preferable, even on 64-bit systems, except for the > case of very large models. Though =E2=80=98scotch32=E2=80=99 is about 32-bit integers, not floating po= int numbers. So I guess it=E2=80=99s not the same kind of tradeoff? Anyway, it sounds like the best course of action is to withdraw this patch and instead come up with multiple variants or package parameters. Thanks for your feedback! Ludo=E2=80=99. From debbugs-submit-bounces@debbugs.gnu.org Fri Mar 19 07:07:37 2021 Received: (at 47237) by debbugs.gnu.org; 19 Mar 2021 11:07:37 +0000 Received: from localhost ([127.0.0.1]:48920 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lNCyf-0001hh-E1 for submit@debbugs.gnu.org; Fri, 19 Mar 2021 07:07:37 -0400 Received: from mail2-relais-roc.national.inria.fr ([192.134.164.83]:59522) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lNCyc-0001hR-6b for 47237@debbugs.gnu.org; Fri, 19 Mar 2021 07:07:36 -0400 IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AGY7phK8h3a/mtQDEo99uk+B/I+orLtY04lQ7?= =?us-ascii?q?vn1ZYxpTb8CeioSSjO0WvCWE8Qo5dVMBvZS7OKeGSW7B7pId2+MsFJqrQQWOgh?= =?us-ascii?q?rMEKhM9o3nqgeQfBHW0s54+eNef7NlCNv2ZGIVse/f7BOjG9gthPmrmZrY59v2?= =?us-ascii?q?9HtmQQF0Z6wI1W4QYTqzKUFuQRkDOJxRLvqhz/BKoDetYh0sH6eGL0MYVOvOrc?= =?us-ascii?q?CjruODXTc6AXccmW+zpALtxrq/NxSDxB8RX3d03L8+/QH+/zDR1+GMtfe0zxOZ?= =?us-ascii?q?+k3yy9BtmNXnwsZeH8DksKUoAwSppACvaoFsH4eHoSlwmuey81wn+eOinz4Qe/?= =?us-ascii?q?9+4X/QYW25yCGN5zXd?= X-IronPort-AV: E=Sophos;i="5.81,261,1610406000"; d="scan'208";a="498867688" X-MGA-submission: =?us-ascii?q?MDGkNF+WN+uOH8xYw38k+It8KatiaGNxLD2ZCm?= =?us-ascii?q?ikkap9Zsl1lq4/cRq3YSyctEKfFpW2e8vGfF8j+QLfKWP4Ea0vLWXQMY?= =?us-ascii?q?6SxpnWI1W2M0/9h4DBHy2DtCTNgJA4s3X0xagEAqpUGUnWueVk9+cYwE?= =?us-ascii?q?mH72Iel0+MpGhnau36MVGBJg=3D=3D?= Received: from zcs-store4.inria.fr ([128.93.142.31]) by mail2-relais-roc.national.inria.fr with ESMTP; 19 Mar 2021 12:07:18 +0100 Date: Fri, 19 Mar 2021 12:07:17 +0100 (CET) From: Emmanuel Agullo To: zimoun Message-ID: <1615735689.2305611.1616152037667.JavaMail.zimbra@inria.fr> In-Reply-To: <86v99ot9po.fsf@gmail.com> References: <20210318150246.7220-1-ludo@gnu.org> <79577287.1930022.1616081242591.JavaMail.zimbra@inria.fr> <86v99ot9po.fsf@gmail.com> Subject: Re: [bug#47237] [PATCH] gnu: metis: Use 64-bit floating pointer numbers on 64-bit architectures. MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Originating-IP: [5.49.130.168] X-Mailer: Zimbra 8.8.15_GA_3996 (ZimbraWebClient - FF84 (Linux)/8.8.15_GA_4007) Thread-Topic: metis: Use 64-bit floating pointer numbers on 64-bit architectures. Thread-Index: tBDsWSsXCfnRFEsfUs/hZZvlENNG3A== X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 47237 Cc: Ludovic =?iso-8859-1?Q?Court=E8s?= , Eric Bavier , Ludovic Courtes , 47237@debbugs.gnu.org, Paul Garlick 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: -3.3 (---) Hi Simon, > I am probably out-of-scope, and it does probably not make sense for > partitioners as Metis, how are considered mixed precision solvers? > i.e., computing some part using 64 bits floating points and other part > using 32 bits. (My memory is not clear but I remember reading couple of > weeks ago an acceleration with 3 levels of float-pointing precision.) > > In the i32_r64 example of convention, what should be considered as rXY? > The final accuracy, whatever the internals? You are right, in principle, there are many combinations we would like to consider and I don't think combinatorial or numerical library developers have followed a unique common rule. I would say that most fully-featured numerical libraries have an interface for all four main floating-point arithmetic (s, d, c, z, to follow blas/lapack convention). Therefore, for most of them, a single package should be enough regarding floating-point arithmetic. The same is true for mixed precision routines (such as the dsgesv mixed precision lapack solver with iterative refinement http://www.netlib.org/lapack/explore-html/d7/d3b/group__double_g_esolve_ga05bea3dc0386868e4720f22c969cb9f5.html ). On the other hand, as I understand, currently, integers are not handled the same way. There is of course always the option to force the compiler to turn all integers in a give arithmetic but advanced combinatorial and numerical codes provider finer strategies. In fully-featured combinatorial codes such scotch (and if I understand metis), the selection is made at compile time. In guix, for instance, the scotch and scotch32 package position INTSIZE64 and INTSIZE32, respectively. [In this case, symbol renaming would be necessary to implement algorithms dealing with subgraphs in 32 bits and other subgraphs in 64 bits (a "mixed integer arithmetic") but I would say that is out of the scope of immediate needs for the guix community, or, that should at least be discussed with library developers ahead of time before being packaged as they may provide facilities in upcoming releases]. The most advanced fully-featured numerical codes may also provide selective 64-bit integers in order to handle large problems while maintaining most arrays in 32-bits (one may want to have a look for instance at the Section 2.6.2 of the 5.3.5 mumps user's guide for such an example http://mumps.enseeiht.fr/doc/userguide_5.3.5.pdf ). This is typically useful for sparse direct solvers (such as mumps) which may have to cope with very large matrices with billions of entries. On the other hand, it is much less common to process such large dense matrices in dense (except possibly for level-1 blas routines), this is why large integer arrays are most often consitently 32 bits in dense routines. To come back to your original question: > In the i32_r64 example of convention, what should be considered as rXY? > The final accuracy, whatever the internals? I would say, at least for now, to focus only on the options that library developers have proposed to position at compile time in their makefiles. For scotch, it is already distinguished through the scotch and scotch32 pakages (however we may still want to make sure the naming convention is clear). For metis, *if I understand correctly*, there is the option to position both integers and floating-point numbers, hence maybe the four combinations that could be considered (but I have no experience in dealing with floating-point numbers in metis). Hope this helps. Best regards, Emmanuel From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 25 13:42:51 2021 Received: (at 47237-done) by debbugs.gnu.org; 25 Mar 2021 17:42:51 +0000 Received: from localhost ([127.0.0.1]:39508 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lPU0R-0006J1-7T for submit@debbugs.gnu.org; Thu, 25 Mar 2021 13:42:51 -0400 Received: from eggs.gnu.org ([209.51.188.92]:34522) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lPU0P-0006In-7z for 47237-done@debbugs.gnu.org; Thu, 25 Mar 2021 13:42:49 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:56337) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lPU0I-0000wR-1K; Thu, 25 Mar 2021 13:42:42 -0400 Received: from [2a01:e0a:1d:7270:af76:b9b:ca24:c465] (port=33660 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lPU0G-00007T-RW; Thu, 25 Mar 2021 13:42:41 -0400 From: =?utf-8?Q?Ludovic_Court=C3=A8s?= To: Paul Garlick Subject: Re: bug#47237: [PATCH] gnu: metis: Use 64-bit floating pointer numbers on 64-bit architectures. References: <20210318150246.7220-1-ludo@gnu.org> <48a8a7c4dbe90415468d8db64cdfd82be52aeb4e.camel@tourbillion-technology.com> <87k0q3iiw4.fsf@gnu.org> Date: Thu, 25 Mar 2021 18:42:39 +0100 In-Reply-To: <87k0q3iiw4.fsf@gnu.org> ("Ludovic =?utf-8?Q?Court=C3=A8s=22'?= =?utf-8?Q?s?= message of "Fri, 19 Mar 2021 10:37:31 +0100") Message-ID: <87sg4j5dv4.fsf_-_@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 47237-done Cc: emmanuel.agullo@inria.fr, bavier@member.fsf.org, 47237-done@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.7 (-) Hi again, For now I=E2=80=99ve added a =E2=80=98metis-r64=E2=80=99 package with 64-bi= t reals to the =E2=80=98guix-hpc=E2=80=99 channel: https://gitlab.inria.fr/guix-hpc/guix-hpc/-/commit/f4a77fe95f0286bd63b07a= f6b9fbef25f3262682 Let=E2=80=99s see later if we can come up with a more generic solution in G= uix proper. Ludo=E2=80=99. From unknown Sat Sep 20 00:51:31 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Fri, 23 Apr 2021 11:24:08 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator