From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 77432 invoked by alias); 22 Sep 2017 14:37:15 -0000 Mailing-List: contact fortran-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: fortran-owner@gcc.gnu.org Received: (qmail 77385 invoked by uid 89); 22 Sep 2017 14:37:14 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=intensive, sk:dominiq, dominiq@lps.ens.fr, U*dominiq X-Spam-User: qpsmtpd, 2 recipients X-HELO: troutmask.apl.washington.edu Received: from troutmask.apl.washington.edu (HELO troutmask.apl.washington.edu) (128.95.76.21) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 22 Sep 2017 14:37:13 +0000 Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id v8MEbAIB018038 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 22 Sep 2017 07:37:11 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id v8MEb9On018037; Fri, 22 Sep 2017 07:37:09 -0700 (PDT) (envelope-from sgk) Date: Fri, 22 Sep 2017 14:37:00 -0000 From: Steve Kargl To: "Dominique =?iso-8859-1?Q?d'Humi=E8res?=" Cc: Janus Weil , gfortran Subject: Re: [Patch, Fortran] PR 82143: add a -fdefault-real-16 flag Message-ID: <20170922143709.GB17729@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) X-IsSubscribed: yes X-SW-Source: 2017-09/txt/msg00085.txt.bz2 On Fri, Sep 22, 2017 at 12:06:12PM +0200, Dominique d'Humières wrote: > > > Le 18 sept. 2017 à 20:13, Janus Weil a écrit : > > > > 2017-09-18 11:31 GMT+02:00 Dominique d'Humières : > >> (1) real(16) is an order of magnitude slower than real(8) for the codes I have tested (a long time ago). So its real utility is quite low. > > > > I am fully aware that performance with quad-precision is lower than > > with double precision. How much will certainly depend on the specifics > > of the code in question. > > Indeed! The polyhedron test protein.f90 goes from 19s to 32s. > > > The flag I'm proposing would help in evaluating this performance hit. > > My memory did not serve me well, for floating point intensive calculations it is not one order of magnitude but two (the one order of magnitude was probably for IBM REAL(16), i.e., two RAL(8)) > test_fpu is a horrible benchmark for testing floating point performance. How big is your L1 and L2 cache? That aside, no one who does numerical computations for a living will ever confuse a software-backed implementation of REAl(16) as being as fast as a hardware-backed implementation of REAL. If a calculation requires 113-bits of precision, it does not matter how fast a 24-bit floating point type is. -- Steve 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 20161221 https://www.youtube.com/watch?v=IbCHE-hONow