This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Performance optimizations for Intel Core 2 and Core i7 processors


On 05/17/2010 02:44 AM, Maxim Kuvyrkov wrote:
CodeSourcery is working on improving performance for Intel's Core 2 and Core i7 families of processors.

CodeSourcery plans to add support for unaligned vector instructions, to provide fine-tuned scheduling support and to update instruction selection and instruction cost models for Core i7 and Core 2 families of processors.

As usual, CodeSourcery will be contributing its work to GCC. Currently, our target is the end of GCC 4.6 Stage1.

If your favorite benchmark significantly under-performs on Core 2 or Core i7 CPUs, don't hesitate asking us to take a look at it.
What I saw is people complaining about -mtune=core2 for polyhedron

http://gcc.gnu.org/ml/gcc-patches/2010-02/msg01272.html

The biggest complaint was on mdbx (about 16%).

I analyzed the benchmark about 2 months ago and the patch in the
attachment solves the problem. These parameters are close to ones in
Intel documentation (originally I used others because that time it worked better
for SPEC2000).


  The patch uses 4 for FADD/FSUB instead of 3 which is in Intel
documentation.  The reason for this in relation with branch cost.  The
different code is generated when <latency of FADD> = branch cost and
<latency of FADD> = branch cost + 1.  This difference is very
important for mdbx which has hot spot code like

if () a = b + c;
if () ...;
if () ...;

and the code after <if> is rarely executed. So it is important not
used conditional insns.  If branch cost is decreased, the overall
performance is worse on other benchmarks.  Changing the current code
generation model (to force generation of code as currently for
<latency of FADD> = branch cost + 1) is not safe because it might
affect other targets.

  Sometimes I have feeling that choosing parameters is close to black
magic, some benchmarks become better, other become worse.  IMHO, one
reason for this is not fully adequate code generation model.  It would be
nice to fix it but as I wrote it is too big project because it affects
other targets.

  Also I think it is important to have a pipeline description for
Core2/Core i7 or at least to use it from generic.

  I think with this patch and the right pipeline description you can
achieve better performance on most benchmarks than one for generic.

  I am glad that Intel is sponsoring this project.  I hope these notes will
be helpful to you, Maxim.  Good luck with this project.


Attachment: core2.patch
Description: Text document


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]