public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Vladimir N. Makarov" <vmakarov@redhat.com>
To: Steven Bosscher <stevenb.gcc@gmail.com>
Cc: Bernd Schmidt <bernds_cb1@t-online.de>,
	        Kenneth Zadeck <zadeck@naturalbridge.com>,
	        gcc-patches <gcc-patches@gcc.gnu.org>,
	        "Park, Seongbae" <seongbae.park@gmail.com>,
	        "Bonzini, Paolo" <bonzini@gnu.org>,
	        Serge Belyshev <belyshev@depni.sinp.msu.ru>,
	richard.earnshaw@arm.com,         echristo@apple.com,
	        "Pinski, Andrew" <andrew_pinski@playstation.sony.com>,
	        "Weigand, Ulrich" <Ulrich.Weigand@de.ibm.com>,
	        Ian Lance Taylor <iant@google.com>,
	        "Edelsohn, David" <dje@watson.ibm.com>,
	        "Berlin, Daniel" <dberlin@dberlin.org>
Subject: Re: dataflow branch merging plans.
Date: Thu, 24 May 2007 22:23:00 -0000	[thread overview]
Message-ID: <46562C36.5090605@redhat.com> (raw)
In-Reply-To: <571f6b510705241344u750c6499r27942cda78f40e32@mail.gmail.com>

Steven Bosscher wrote:

> On 5/24/07, Bernd Schmidt <bernds_cb1@t-online.de> wrote:
>
>> Kenneth Zadeck wrote:
>> > I believe that the dataflow branch is now ready to merge into the
>> > mainline.  We have fixed almost all of the performance problems
>> > associated with it.  While there are still some left, we feel
>> > confident that these can be addressed during the rest of stage I and
>> > during stage II.
>>
>> Vlad's last benchmark run still showed up to 11% compile time
>> regression, didn't it?
>
>
> No, 8% in ia64, and somewhere between 5% and 6% on the other targets
> Vlad's tested.

Yes, 11% is the worst dataflow branch compile time regression which is 
achieved on SPEC2000 on Itanium.  8% is on SPECINT on Itanium.

>   Note that the scheduler on ia64
> is already dog slow even on the trunk. The DFA for Itanium is the
> problem here.

Scheduler is slow on Itanium.  That is true.  But the DFA (used for fast 
pipeline hazard recognizing) was a big step forward.  It sped up all 
Itanium compiler (not only scheduler) up to 2 times and give about 3% 
improvement on SPECINT2000 (which is much harder then get the same 
improvement on SPECFP2000).  You can read more details about it in my 
artcile for the 1st GCC summit.

I am not saying that there is no better solution.  I encorauge you to 
write the scheduler (and insn bundling) faster and better without the 
DFA.  Although I should say that usage of DFA is common practise for 
Itanium schedulers.  For example, Open64 got this a few years later than 
GCC.

By the way, if you switch off scheduler (-fno-schedule-insns and 
-fno-schedule-insns2) the datafalow branch compilation speed degradation 
on Itanium will be not 11% but almost 14% on SPECFP2000.

Steven, I really value your help in rewriting old pipileine descriptions 
to the DFA ones but  please be more accurate when you jump the 
conclusion like "the DFA for Itanium is the problem here" or saying on 
IRC that most interesting work on the DFA was done by Zack.  That is not 
true.

  reply	other threads:[~2007-05-24 22:19 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-23 13:19 Kenneth Zadeck
2007-05-24  1:29 ` Andrew_Pinski
2007-05-24  7:51   ` Paolo Bonzini
2007-05-24  8:12     ` Paolo Bonzini
2007-05-24 11:47 ` Bernd Schmidt
2007-05-24 20:02   ` Kenneth Zadeck
2007-05-25  9:51     ` Bernd Schmidt
2007-05-25 10:32       ` Paolo Bonzini
2007-05-25 13:00       ` Kenneth Zadeck
2007-05-28 20:55       ` Mark Mitchell
2007-05-29  1:16         ` Kenneth Zadeck
2007-05-29 15:58           ` Mark Mitchell
2007-05-24 21:09   ` Steven Bosscher
2007-05-24 22:23     ` Vladimir N. Makarov [this message]
2007-05-24 23:03       ` Steven Bosscher
2007-05-25 13:50         ` Vladimir N. Makarov
2007-05-25 17:15           ` Richard Sandiford
2007-05-25 18:21             ` Jan Hubicka
2007-05-25 20:13             ` Steven Bosscher
2007-05-25 20:11           ` Steven Bosscher
     [not found] <OF781E582C.3916D180-ON882572E5.00078CD6-882572E5.00082C95@LocalDomain>
2007-05-25  0:12 ` Andrew_Pinski
2007-05-25 19:04 Zack Weinberg
     [not found] <OF1BD0F1DA.E933CF3F-ON422572E9.006B2EF9-422572E9.006B85BF@de.ibm.com>
2007-05-29  1:05 ` Kenneth Zadeck
2007-05-30 13:11   ` Andreas Krebbel1
2007-05-30 14:17     ` Kenneth Zadeck

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=46562C36.5090605@redhat.com \
    --to=vmakarov@redhat.com \
    --cc=Ulrich.Weigand@de.ibm.com \
    --cc=andrew_pinski@playstation.sony.com \
    --cc=belyshev@depni.sinp.msu.ru \
    --cc=bernds_cb1@t-online.de \
    --cc=bonzini@gnu.org \
    --cc=dberlin@dberlin.org \
    --cc=dje@watson.ibm.com \
    --cc=echristo@apple.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=iant@google.com \
    --cc=richard.earnshaw@arm.com \
    --cc=seongbae.park@gmail.com \
    --cc=stevenb.gcc@gmail.com \
    --cc=zadeck@naturalbridge.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).