public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Steve Ellcey <sellcey@cavium.com>
To: Richard Biener <richard.guenther@gmail.com>,
		pmenzel+gcc.gnu.org@molgen.mpg.de
Cc: GCC Development <gcc@gcc.gnu.org>
Subject: Re: How to get GCC on par with ICC?
Date: Fri, 08 Jun 2018 22:08:00 -0000	[thread overview]
Message-ID: <1528494436.3449.36.camel@cavium.com> (raw)
In-Reply-To: <CAFiYyc1rpbWREjd8AS3s-uCgsJVX7kqKh_tyjSTysTvpyjieVw@mail.gmail.com>

On Thu, 2018-06-07 at 12:01 +0200, Richard Biener wrote:
> 
> When we do our own comparisons of GCC vs. ICC on benchmarks
> like SPEC CPU 2006/2017 ICC doesn't have a big lead over GCC
> (in fact it even trails in some benchmarks) unless you get to
> "SPEC tricks" like data structure re-organization optimizations that
> probably never apply in practice on real-world code (and people
> should fix such things at the source level being pointed at them
> via actually profiling their codes).

Richard,

I was wondering if you have any more details about these comparisions
you have done that you can share?  Compiler versions, options used,
hardware, etc  Also, were there any tests that stood out in terms of
icc outperforming GCC?

I did a compare of SPEC 2017 rate using GCC 8.* (pre release) and
a recent ICC (2018.0.128?) on my desktop (Xeon CPU E5-1650 v4).
I used '-xHost -O3' for icc and '-march=native -mtune=native -O3'
for gcc.

The int rate numbers (running 1 copy only) were not too bad, GCC was
only about 2% slower and only 525.x264_r seemed way slower with GCC.
The fp rate numbers (again only 1 copy) showed a larger difference, 
around 20%.  521.wrf_r was more than twice as slow when compiled with
GCC instead of ICC and 503.bwaves_r and 510.parest_r also showed
significant slowdowns when compiled with GCC vs. ICC.

Steve Ellcey
sellcey@cavium.com

  reply	other threads:[~2018-06-08 21:47 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
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 [this message]
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=1528494436.3449.36.camel@cavium.com \
    --to=sellcey@cavium.com \
    --cc=gcc@gcc.gnu.org \
    --cc=pmenzel+gcc.gnu.org@molgen.mpg.de \
    --cc=richard.guenther@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).