From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20282 invoked by alias); 15 Jun 2018 15:26:26 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 20272 invoked by uid 89); 15 Jun 2018 15:26:25 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=H*f:sk:DB5PR08, H*i:sk:DB5PR08, retry X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 15 Jun 2018 15:26:24 +0000 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 8E7DB3082149; Fri, 15 Jun 2018 15:26:23 +0000 (UTC) Received: from localhost.localdomain (ovpn-112-19.rdu2.redhat.com [10.10.112.19]) by smtp.corp.redhat.com (Postfix) with ESMTP id B760910ADCC7; Fri, 15 Jun 2018 15:26:21 +0000 (UTC) Subject: Re: How to get GCC on par with ICC? To: Wilco Dijkstra , "mjambor@suse.cz" Cc: "gcc@gcc.gnu.org" , nd , Steve Ellcey , Richard Biener , "pmenzel+gcc.gnu.org@molgen.mpg.de" References: From: Jeff Law Openpgp: preference=signencrypt Message-ID: Date: Fri, 15 Jun 2018 17:03:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2018-06/txt/msg00181.txt.bz2 On 06/15/2018 05:39 AM, Wilco Dijkstra wrote: > Martin wrote: > >> Keep in mind that when discussing FP benchmarks, the used math library >> can be (almost) as important as the compiler. In the case of 481.wrf, >> we found that the GCC 8 + glibc 2.26 (so the "out-of-the box" GNU) >> performance is about 70% of ICC's. When we just linked against AMD's >> libm, we got to 83%. When we instructed GCC to generate calls to Intel's >> SVML library and linked against it, we got to 91%. Using both SVML and >> AMD's libm, we achieved 93%. >> >> That means that there likely still is 7% to be gained from more clever >> optimizations in GCC but the real problem is in GNU libm. And 481.wrf >> is perhaps the most extreme example but definitely not the only one. > > You really should retry with GLIBC 2.27 since several key math functions were > rewritten from scratch by Szabolcs Nagy (all in generic C code), resulting in huge > performance gains on all targets (eg. wrf improved over 50%). > > I fixed several double precision functions in current GLIBC to avoid extremely bad > performance which had been complained about for years. There are more math > functions on the way, so the GNU libm will not only catch up, but become the fastest > math library available. And resolution on -fno-math-errno as the default. Setting errno can be more expensive than people realize. Jeff