public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jan Hubicka <jh@suse.cz>
To: Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at>
Cc: Nathanael Nerode <neroden@twcny.rr.com>, gcc@gcc.gnu.org
Subject: Re: GCC still getting a lot slower
Date: Thu, 02 Jan 2003 14:21:00 -0000	[thread overview]
Message-ID: <20030102142107.GA21227@kam.mff.cuni.cz> (raw)
In-Reply-To: <Pine.BSF.4.51.0301021148470.62618@naos.dbai.tuwien.ac.at>

> On Tue, 31 Dec 2002, Nathanael Nerode wrote:
> > Can we test compile time change of some *fixed* piece of code, perhaps?
> 
> PR 8361 (http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=8361),
> which is basically the old PR 3083, is here for anyone to use. ;-)
> 
> Gerald
> 
> PS: It's no longer a completely fixed piece of code, as it's not possible
> to have preprocessed source that is forwards or backwards compatible with
> or from current mainline, but I have included two preprocessed files now.
It would be perhaps good idea to include the performance of preprocesing
as well.  That would fix the compatibility too.

For C performance I think it can be practical to just benchmark linux
kernel build - it is fixed piece as it does not include any external
headers, large enought to make measurements hopefully stable enought and
tests performance of "usual hand writen C program" that (for C) is about
the most important.  Fixing performance of computer generated code is
important too, but it usually has different problem (like computed
jumps, large switch statements and so on) and I tend to believe that
still most of code is hand writen.
I did some oprofiling in the past on this but didn't find anything
obvious to fix.

For C++ I am not aware of something like that.
> -- 
> Gerald "Jerry"   pfeifer@dbai.tuwien.ac.at   http://www.pfeifer.com/gerald/

  reply	other threads:[~2003-01-02 14:21 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-31 14:11 Nathanael Nerode
2002-12-31 14:49 ` Paul Jarc
2002-12-31 17:16 ` Diego Novillo
2003-01-02 10:59 ` Gerald Pfeifer
2003-01-02 14:21   ` Jan Hubicka [this message]
2003-01-03  0:21     ` Fergus Henderson
2003-01-03 14:05       ` Jan Hubicka
2003-01-03 10:33     ` Ben Elliston
     [not found] <1041382480.23232.35.camel@steven>
2003-01-02 14:24 ` Jan Hubicka
  -- strict thread matches above, loose matches on Subject: below --
2002-12-31 23:01 Ritzert
2002-12-31 16:14 Nathanael Nerode
2002-12-31 16:53 ` Paul Jarc
2002-12-31 13:44 Neil Booth
2002-12-31 13:47 ` Paolo Carlini
2002-12-31 13:48   ` Neil Booth
2002-12-31 13:55     ` Paolo Carlini
2002-12-31 14:00       ` Neil Booth
2002-12-31 20:22         ` David Edelsohn
2002-12-31 14:00   ` Diego Novillo

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=20030102142107.GA21227@kam.mff.cuni.cz \
    --to=jh@suse.cz \
    --cc=gcc@gcc.gnu.org \
    --cc=neroden@twcny.rr.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).