This is the mail archive of the egcs@egcs.cygnus.com mailing list for the EGCS project. See the EGCS home page for more information.
On Sun, Jan 31, 1999 at 05:59:28PM -0700, Jeffrey A Law wrote:
> > If you want a good and fast compiler and do not need the new C++ features
> > of egcs, then by all means stay with gcc. If you really need speed, use
> > pgcc, but -O6 -funroll-all-loops, pgcc isn't faster than gcc with -O3.
I was just told that his findings are now online (at
http://members.xoom.com/Alex_Maranda)
> > Of course, that was his own (maybe limited) benchmark, but thats what
> > counts for him. I also reeceived quite a few similar reports, but these
> > didn't have hard data in it, i.e. "nothing to report to egcs".
> Such is life. The benchmarks I've run show just the opposite.
btw, did you benchmark 1.1.1 or the current snapshot? 1.1.1 seems to be
slower than gcc-2.8 with every benchmark _I_ tried, and I guess thats what
people test. The snapshots, however, are faster.
> benchmark it. That's always the best indicator of performance -- running
> your own code.
;)
> And such ports are interesting in that they tell us we need to continue to
> improve the compiler. However, I'm much more likely to spend time working
> with someone that's going to take the time to help analyze the problem. For
> example, Zack is taking the time to analyze the code and point out problems.
> And I'm more than happy to work with Zack to try and nail down these problems.
More happy than? I'm quite happy when somebody comes at least with hard
data (i.e. something to reproduce). The problem (which is hopefully solved at
leats in part) is the high-quality test-suite and the non-existant benchmark
suite.
Correct code is more important (and there is the high quality of the egcs
releases with respect to correctness!) than fast code. I actually hope
to prove that the current codebase is atcually superior. For example, it
often only takes a simple "-O3 -funroll-all-loops" to make code run (much
faster than gcc-2.8 with the same options).
> And finally, with the ongoing issues with alignment of stack slots, I'm
> leery of any FP benchmarks. It's too difficult to get reliable benchmark
> results with the FP numbers varying so wildly due to alignment issues.
Its not that difficult with all alignment options on
(-mstack-align-double, -marg-align-double) ;-> Anyway, a very good way to
improve this would be to -fschedule-insns only on fp-intensive code (on
x86). (I do plan to implement this, next year or so.. ;)
> In fact, I was looking at the losing caller saves stuff today, and gee, fpppp
> started running about 50% slower than normal. What was it tracked down to?
> A call earlier in call stack allowing 4 less bytes of space caused the main
> code to run a hell of a lot slower.
Thats symptomatic of misaligned stuff. But it gets even worse: on
linux-kernel there is a dicsussion about code which runs twice as
fast with a different virtual memory configuration (linux doesn't do
cache-colouring). Using the _same_ code, of course.
Anyway, wasn't I told recently on egcs that stack-alignment of double
variables is not really worth the effort (according to benchmarks? ;)
> > Maybe you can hint me to some of the smaller ones? The current benchmark
> > suite is quite sensible to small code changes (which was one of the
> > goals), but it does not provide an adequate view on the performance on
> > real world problems.
> gcc, sc, perl, compress, m88ksim. None of which are particularly small, but
> I think all are available in various locations on the net. Then you just have
> to come up with datasets.
>
> I believe perl comes with a testsuite, if so, that could become the input
> data. For gcc, select a target and generate a bunch of .i files (possibly
> the compiler itself) as input.
>
> Compress? How about compressing the gcc tarball. Obviously you have to
> pick one and stick with it, but that's not hard.
>
> m88k sim? Dunno. Depends on how complete the simulator is. One could feed
> the simulator small free benchmarks. Since what you're measuring is the
> simulator, not the end benchmark.
>
> John Wehle does benchmarking with craftychess, and I'm sure if we looked around
Interesting note: Robert Hyatt (craftys author) actually recommends "pgcc
-O" (which _should_ be almost the same as "egcs -O"). Veeery interesting.
> we could find some nontrivial fp intensive benchmarks.
My (and your) primary concerns with regards to the benchmark suite were
space constraints. If nobody minds the ("few") additional megabytes I'd be
happy to put in more complete tests. (thanks for the ideas!)
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / pcg@goof.com |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|