From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 98125 invoked by alias); 7 Jun 2018 09:54:05 -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 98095 invoked by uid 89); 7 Jun 2018 09:54:05 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.0 required=5.0 tests=AWL,BAYES_50,FREEMAIL_FROM,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=Ryan, ryan, burn, 1,000,000 X-HELO: mail-lf0-f53.google.com Received: from mail-lf0-f53.google.com (HELO mail-lf0-f53.google.com) (209.85.215.53) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 07 Jun 2018 09:54:01 +0000 Received: by mail-lf0-f53.google.com with SMTP id n15-v6so13675710lfn.10 for ; Thu, 07 Jun 2018 02:54:00 -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:content-transfer-encoding; bh=/FfHniV451fya63wGnRyJdPgrThNDJVKMuEmxGbEsTk=; b=Ped5JUxnYXGfg0KEgX57aEYZTUpWI2Ve4GdmvcI1vP5sRXRYZQ3fdj/mYai1Ka3dzN gLBnyzErwc3AN6jOe23u+vcciwyZOUC7Ey5baH7Y4sRxgFucc0EEF7V1b17ghsnjsyBO TgcOX2/Q/xqI5/O3s7nsi25Oo6Fi5b+z0RnbVXyTKBSg8NZn74SvP2eVGtN3V2wAIGZT TuEy3HWkyI3jElK9PprmaZqVyJN0R2fDdrmwLG6tU6uAZ9VMbBgh4Zkk84AkpWgy2/70 KBMt2UOpgmAIc1NnwHXWgV/t1HHhgQ75uQOfYCRiGQeB/xn3LXsWg/MJq4SiAN2roO6c h+Nw== X-Gm-Message-State: APt69E0ilugSyeqgYQq6BjDj+bMQUcOOlen7rD3T5mdTFP9gXPWRM6ze OvWZLPKR1KEzBqRjUgWnu9MGFfx4M5g8lWfy9qI= X-Google-Smtp-Source: ADUXVKKQuNswvndIvSmUXAat4Jof5QnlJyjRgxLLerkufOG98tSyIjxZS6wgNxq6O7+8XAPD04uV0FU1pv3ye+F3C6c= X-Received: by 2002:a2e:5687:: with SMTP id k7-v6mr1031682lje.140.1528365239182; Thu, 07 Jun 2018 02:53:59 -0700 (PDT) MIME-Version: 1.0 References: <01126195-f718-7dd0-063b-6997e5b82559@molgen.mpg.de> In-Reply-To: From: Richard Biener Date: Thu, 07 Jun 2018 10:02:00 -0000 Message-ID: Subject: Re: How to get GCC on par with ICC? To: rnickb731@gmail.com Cc: dmitry@kernelgen.org, pmenzel+gcc.gnu.org@molgen.mpg.de, GCC Development Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2018-06/txt/msg00094.txt.bz2 On Wed, Jun 6, 2018 at 8:31 PM Ryan Burn wrote: > > One case where ICC can generate much faster code sometimes is by using > the nontemporal pragma [https://software.intel.com/en-us/node/524559] > with loops. > > AFAIK, there's no such equivalent pragma in gcc > [https://gcc.gnu.org/ml/gcc/2012-01/msg00028.html]. > > When I tried this simple example > https://github.com/rnburn/square_timing/blob/master/bench.cpp that > measures times for this loop: > > void compute(const double* x, index_t N, double* y) { > #pragma vector nontemporal > for(index_t i=3D0; i } > > with and without nontemporal I got these times (N =3D 1,000,000) > > Temporal 1,042,080 > Non-Temporal 538,842 > > So running with the non-temporal pragma was nearly twice as fast. > > An equivalent non-temporal pragma for GCC would, IMO, certainly be a > very good feature to add. GCC has robust infrastructure for loop pragmas now just the set of pragmas available isn't very big. It would be interesting to know which ICC ones p= eople use regularly so we can support those in GCC as well. Note using #pragmas is very much hand-optimizing the code for the compiler you use - sth that is possible for GCC as well. Richard. > On Wed, Jun 6, 2018 at 12:22 PM, Dmitry Mikushin w= rote: > > Dear Paul, > > > > 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 instanc= e, > > when you do "-O3" for Intel it actually corresponds to (at least) "-O3 > > -ffast-math -march=3Dnative" of GCC. Omitting "-ffast-math" obviously > > introduces significant performance gap. > > > > Kind regards, > > - Dmitry Mikushin | Applied Parallel Computing LLC | > > https://parallel-computing.pro > > > > > > 2018-06-06 18:51 GMT+03:00 Paul Menzel : > > > >> Dear GCC folks, > >> > >> > >> Some scientists in our organization still want to use the Intel compil= er, > >> as they say, it produces faster code, which is then executed on cluste= rs. > >> Some resources on the Web [1][2] confirm this. (I am aware, that it=E2= =80=99s > >> heavily dependent on the actual program.) > >> > >> My question is, is it realistic, that GCC could catch up and that the > >> scientists will start to use it over Intel=E2=80=99s compiler? Or will= Intel > >> developers always have the lead, because they have secret documentatio= n and > >> direct contact with the processor designers? > >> > >> If it is realistic, how can we get there? Would first the program be > >> written, and then the compiler be optimized for that? Or are just more= GCC > >> developers needed? > >> > >> > >> Kind regards, > >> > >> Paul > >> > >> > >> [1]: https://colfaxresearch.com/compiler-comparison/ > >> [2]: http://citeseerx.ist.psu.edu/viewdoc/download?doi=3D10.1.1.679 > >> .1280&rep=3Drep1&type=3Dpdf > >> > >>