From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 91319 invoked by alias); 7 Jun 2018 09:52:03 -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 91307 invoked by uid 89); 7 Jun 2018 09:52:03 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=inconvenience, H*f:sk:0edea08, H*i:sk:0edea08, risk X-HELO: mail-lf0-f47.google.com Received: from mail-lf0-f47.google.com (HELO mail-lf0-f47.google.com) (209.85.215.47) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 07 Jun 2018 09:52:01 +0000 Received: by mail-lf0-f47.google.com with SMTP id g21-v6so11704508lfb.4 for ; Thu, 07 Jun 2018 02:52:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xwTj5GcxSFOM6oIDmPnz2mJcEp2RP6cfe01L/H7mH28=; b=Y47Rdv++Bg94zaF+F/Th2rgUYdHiJAeo1TH6fJO/oLVhAAh/vIdaqicGIOD/N3dA16 huJM3ocg2s0farfz18L13YK4e8sO077SqIDmtPtM6hF+kVyOhpBrazdzfLyyj2wWedrF XBd1K4517VB8Y7Sx6yHkhSvlTx0Zi3IdvCRXB1S5QP8jt5zSk96AnaRPzA9r4Z4toTPo cHgxTsodfU6e0fNTheR4Pww0hGtLwl8Y0pG5CWXrg9O/F1tGtyJaOjBVjRIlxcxbeids OzrvWsX3qpUQnYhNBZvAT/qMLQcqbzgjP5ylY2GGKTvmu1wwvrp+O7WMb2bdPK5cRxbt bSJw== X-Gm-Message-State: APt69E3i2wGAZABr5izqwECBIs8y4oXMFFa/O3sL5OxI6ldVmZHHZNbW C9XYt83bKFR+iH/1WbulbEPDZm7mN50sdmZmYb/WiA== X-Google-Smtp-Source: ADUXVKLGWtaVHP6DSlHOE2rQkmFMPEyFUYemnpplwyoNCLjUj1JR96KQSHftgxoRkV9gRyZqHVlfOelJFmirGBP4KYQ= X-Received: by 2002:a19:5512:: with SMTP id n18-v6mr763996lfe.133.1528365119535; Thu, 07 Jun 2018 02:51:59 -0700 (PDT) MIME-Version: 1.0 References: <01126195-f718-7dd0-063b-6997e5b82559@molgen.mpg.de> <0edea081-246f-6192-ae74-f55b2b23df5c@acm.org> In-Reply-To: <0edea081-246f-6192-ae74-f55b2b23df5c@acm.org> From: Richard Biener Date: Thu, 07 Jun 2018 09:54:00 -0000 Message-ID: Subject: Re: How to get GCC on par with ICC? To: zlynx@acm.org Cc: pmenzel+gcc.gnu.org@molgen.mpg.de, GCC Development Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018-06/txt/msg00093.txt.bz2 On Wed, Jun 6, 2018 at 11:10 PM Zan Lynx wrote: > > On 06/06/2018 10:22 AM, Dmitry Mikushin wrote: > > The opinion you've mentioned is common in scientific community. However, in > > more detail it often surfaces that the used set of GCC compiler options > > simply does not correspond to that "fast" version of Intel. For instance, > > when you do "-O3" for Intel it actually corresponds to (at least) "-O3 > > -ffast-math -march=native" of GCC. Omitting "-ffast-math" obviously > > introduces significant performance gap. > > > > Please note that if your compute cluster uses different models of CPU, > be extremely careful with -march=native. > > I've been bitten by it in VMs, several times. Unless you always run on > the same system that did the build, you are running a risk of illegal > instructions. Yes. Note this is where ICC has an advantage because it supports automagically doing runtime versioning based on the CPU instruction set for vectorized loops. We only support that in an awkward explicit way (the manual talks about this in the 'Function Multiversioning' section). But in the end it's just a "detail" that can be worked around with a little inconvenience ;) (I've yet to see a heterogenous cluster where the instruction set differences make a performance difference over choosing the lowest common one) Richard. > -- > Knowledge is Power -- Power Corrupts > Study Hard -- Be Evil