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.
next prev parent 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).