public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Daniel Berlin <dan@cgsoftware.com>
To: Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at>
Cc: Mark Mitchell <mark@codesourcery.com>,
	Joe Buck <jbuck@synopsys.com>,
	"gcc@gcc.gnu.org" <gcc@gcc.gnu.org>
Subject: Re: C++ compile-time regressions (was: GCC 3.0.1 Status Report)
Date: Mon, 23 Jul 2001 11:54:00 -0000	[thread overview]
Message-ID: <877kwzearp.fsf@cgsoftware.com> (raw)
In-Reply-To: <Pine.BSF.4.33.0107231933360.90992-100000@deneb.dbai.tuwien.ac.at>

Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> writes:

> On Fri, 20 Jul 2001, Mark Mitchell wrote:
>>> you'll see that C++ projects heavily relying on STL apparently
>>> simply cannot use GCC 3.0.
>> An extreme statement, but, that aside, as you know people are working
>> on fixes.
> 
> Yes, and I really appreciate that.
> 
> And I especially hope that our new development model will make prevention
> of such problems easier by providing a much more stable head branch that
> we can benchmark against regularily.
> 
> On Fri, 20 Jul 2001, Joe Buck wrote:
>> Gerald, could you test Daniel's change and see if it helps on your code?
> 
> Of course! Here we go:
> 
>           GCC 2.95.3           GCC 3.0          GCC 3.0.1-pre
>          Time    Size        Time   Size         Time   Size
>   -O0    6:19    3915128     8:20   4159780      8:00   4159588
>   -O1    4:20    4203480    11:40   4829732      7:09   3997668
>   -O2    5:56    4209368    14:09   4862532      7:53   3987556
>   -O3    5:47    4221464    32:04   6166052      7:54   3987140
> 
> The huge compile-time regression is gone, though we are still noticably
> slower than GCC 2.95; and binary size is even better than it used to be.
> 
> That is, there is still work to do to make the compiler faster, but it's
> *much* nicer now.
> 

Tree based optimizations should help on making it faster, as well as
the new parser.
After that our new bottlenecks *should* be (and if they aren't,
we should be able to  make it so they are):

1. Scheduling.
2. Register Allocation.
3. Instruction combiner.


With the store motion changes, we can turn off CSE follow-jumps and
skip-blocks. I tested it, and got the same performance with those off,
and with them on.  Without the store motion fixes i submitted, and
aren't reviewed yet, we'll get slower code with those off.

With follow-jumps and skip-blocks on, CSE takes longer than GCSE with
store motion fixed.
This is kinda silly, since it's a local algorithm.

If GCSE still takes too long (It seems to be a constant 12% of the
time, when i start throwing large enough stuff that it's time isn't
lost in the noise), we can convert to SSA based PRE.
Past that, e very other compiler i know of started using region based compiling
(HP's ELCOR, SGI Pro64, SGI's mipspro, Intel's compilers,
IBM's compilers, etc) in order to cut down the compile time while speeding
up the code.

From what i understand, it works quite well.

Some tried flat interprocedural analysis, but it was too slow.  Some
still do it for alias analysis, however.

--Dan



> About run-time performance, I'll report later when tests have been
> finished.
> 
> Gerald
> -- 
> 
> Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

-- 
"I bought my brother some gift-wrap for Christmas.  I took it to
the Gift Wrap Department and told them to wrap it, but in a
different print so he would know when to stop unwrapping.
"-Steven Wright

  parent reply	other threads:[~2001-07-23 11:54 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-07-18 18:41 GCC 3.0.1 Status Report Mark Mitchell
2001-07-19  6:17 ` Joseph S. Myers
2001-07-20  3:45 ` Nathan Sidwell
2001-07-20 10:26 ` C++ compile-time regressions (was: GCC 3.0.1 Status Report) Gerald Pfeifer
2001-07-20 10:54   ` Nathan Sidwell
2001-07-20 16:41     ` Loren James Rittle
2001-07-23  5:17       ` Gerald Pfeifer
2001-07-23 11:56       ` Daniel Berlin
2001-07-23  2:51     ` Gerald Pfeifer
2001-07-20 10:55   ` Mark Mitchell
2001-07-20 14:22     ` Joe Buck
2001-07-20 16:28       ` Mark Mitchell
2001-07-20 21:05         ` Joe Buck
2001-07-23 10:44           ` Gerald Pfeifer
2001-07-23 11:12             ` Joe Buck
2001-07-23 11:57               ` Gerald Pfeifer
2001-07-23 13:30                 ` Joe Buck
2001-07-24  7:18                   ` Gerald Pfeifer
2001-07-24  7:55                     ` Daniel Berlin
2001-07-24 10:09                     ` Joe Buck
2001-07-24 10:19                       ` Gabriel Dos Reis
2001-07-24 10:44                         ` Joe Buck
2001-07-24 10:56                           ` Gabriel Dos Reis
2001-07-24 10:25                       ` Daniel Berlin
2001-07-24 10:49                         ` Joe Buck
2001-07-24 11:08                           ` Daniel Berlin
2001-07-23 14:36                 ` Mark Mitchell
2001-07-25  8:06                   ` Gerald Pfeifer
2001-08-02  0:20                     ` C++ compile-time regressions Gerald Pfeifer
2001-08-02  0:26                       ` Mark Mitchell
2001-08-02 11:00                       ` aoliva
2001-08-02 12:00                         ` Mark Mitchell
2001-08-02 12:26                           ` aoliva
2001-08-02 12:37                             ` Joe Buck
2001-08-02 12:41                             ` Mark Mitchell
2001-08-02 12:48                               ` Joe Buck
2001-08-02 13:53                       ` Daniel Berlin
2001-08-07  7:54                         ` Gerald Pfeifer
2001-07-23 11:54             ` Daniel Berlin [this message]
2001-07-23 12:42               ` C++ compile-time regressions (was: GCC 3.0.1 Status Report) Bernd Schmidt
2001-07-23 12:50               ` law
2001-07-23 13:15                 ` Daniel Berlin
2001-07-23 14:00                   ` law
2001-07-20 10:57   ` Daniel Berlin
2001-07-20 14:20   ` Joe Buck
2001-07-25 17:52 ` GCC 3.0.1 Status Report Marc Espie
2001-08-13 23:15   ` Mark Mitchell

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=877kwzearp.fsf@cgsoftware.com \
    --to=dan@cgsoftware.com \
    --cc=gcc@gcc.gnu.org \
    --cc=jbuck@synopsys.com \
    --cc=mark@codesourcery.com \
    --cc=pfeifer@dbai.tuwien.ac.at \
    /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).