public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Biener <richard.guenther@gmail.com>
To: rnickb731@gmail.com
Cc: dmitry@kernelgen.org, pmenzel+gcc.gnu.org@molgen.mpg.de,
		GCC Development <gcc@gcc.gnu.org>
Subject: Re: How to get GCC on par with ICC?
Date: Thu, 07 Jun 2018 10:02:00 -0000	[thread overview]
Message-ID: <CAFiYyc08i_U7JW2d2E5AWJ21wOfuU_YkCLwio3PtxWtsr+8sHg@mail.gmail.com> (raw)
In-Reply-To: <CACqP_ww8H2jpiqoL7w7BXOipH48LqOCjrU0zjYsVLGHbu6odfg@mail.gmail.com>

On Wed, Jun 6, 2018 at 8:31 PM Ryan Burn <rnickb731@gmail.com> 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=0; i<N; ++i) y[i] = x[i]*x[i];
> }
>
>  with and without nontemporal I got these times (N = 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 people
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 <dmitry@kernelgen.org> wrote:
> > 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 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.
> >
> > Kind regards,
> > - Dmitry Mikushin | Applied Parallel Computing LLC |
> > https://parallel-computing.pro
> >
> >
> > 2018-06-06 18:51 GMT+03:00 Paul Menzel <pmenzel+gcc.gnu.org@molgen.mpg.de>:
> >
> >> Dear GCC folks,
> >>
> >>
> >> Some scientists in our organization still want to use the Intel compiler,
> >> as they say, it produces faster code, which is then executed on clusters.
> >> Some resources on the Web [1][2] confirm this. (I am aware, that it’s
> >> 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’s compiler? Or will Intel
> >> developers always have the lead, because they have secret documentation 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=10.1.1.679
> >> .1280&rep=rep1&type=pdf
> >>
> >>

  reply	other threads:[~2018-06-07  9:54 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-06 15:57 Paul Menzel
2018-06-06 16:14 ` Joel Sherrill
2018-06-06 16:20   ` Paul Menzel
2018-06-20 22:42   ` NightStrike
2018-06-21  9:20     ` Richard Biener
2018-06-22  0:48     ` Steve Ellcey
2018-06-06 16:22 ` Bin.Cheng
2018-06-06 18:31 ` Dmitry Mikushin
2018-06-06 21:10   ` Ryan Burn
2018-06-07 10:02     ` Richard Biener [this message]
2018-06-06 22:43   ` Zan Lynx
2018-06-07  9:54     ` Richard Biener
2018-06-07 10:06 ` Richard Biener
2018-06-08 22:08   ` Steve Ellcey
2018-06-09 15:32     ` Marc Glisse
2018-06-11 14:50     ` Martin Jambor
2018-06-22 22:41       ` Szabolcs Nagy
2018-06-15 11:48 Wilco Dijkstra
2018-06-15 17:03 ` Jeff Law
2018-06-15 18:01   ` Joseph Myers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAFiYyc08i_U7JW2d2E5AWJ21wOfuU_YkCLwio3PtxWtsr+8sHg@mail.gmail.com \
    --to=richard.guenther@gmail.com \
    --cc=dmitry@kernelgen.org \
    --cc=gcc@gcc.gnu.org \
    --cc=pmenzel+gcc.gnu.org@molgen.mpg.de \
    --cc=rnickb731@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).