Re: C++: EGCS perf. vs GCC

Re: C++: EGCS perf. vs GCC

[Alex Maranda]

please read below

Alex Maranda         mailto: amaranda@spider.com
Spider Software Ltd. Tel: +44 (0)131 4757036
Edinburgh, UK        http://members.xoom.com/Alex_Maranda
STREAMS based communications protocols for embedded systems

On Thu, 10 Dec 1998, Casper Dik wrote:

> 
> 
> I couldn't help noticing your posts.  
> 
I've stopped eventually :-), but I'll strike back any time now, as I've
learned that the key optimisations vs. instruction scheduling are
activated for pgcc by -O6; I've only benchmarked with -O3.

> 
> I was wondering whether you used egcs/gcc for SPARC as well.
for my daily job...I don't have an Ultra II/333Mhz on my desk though, so a
comparison with the PII/350 at home would be meaningless.

> 
> I'm aware that gcc 2.8.1 sucks compared to Sun's compiler; I don't
> know whether egcs is really all that much better.
Now that's an unfair comment; I've read the paper a couple of weeks ago. I
will never claim that gcc is better than Sun's CC, but there is no
reference in the paper as for the flags used (just a general statement
like: 'tuned for optimum performance').

> 
> If you wish, there's an evaluation copy of Sun's C/C++ compilers
> available from access1.Sun.com  (the new C++ compiler should
> be much more standards compliant and generate *much* better code
> for UltraSPARC than our older compiler).
Most annoying in the article is the comparison between the Workshop and
the command-line gdb; when looking at the latest DDD I can understand
Sun's fears :-)

> 
> Othewrwrise, if you benchmark is easy to perform (self-contained and
> such) I'd be happy to compare egcs & Sun C results on my Ultra.
Yes and no. It is extremely easy for me to set it up, but then I wrote the
network simulator myself. You will have to install a GUI and use it to
start the simulation, and modify a CFLAGS macro in a Makefile when you
change flags. And of course recompile a library and the simulation
executable. It's easier than it sounds, it takes me less than a minute
(well, maybe two :-) to produce a new executable.
Have a look at:
http://members.xoom.com/Alex_Maranda/NetSim++/home.html

If your machine is Ultra II/ 300,333Mhz I am definitely interested. With
the side comment that the outcome of the benchmark is irrelevant for the
previous x86 thread, and most relevant for the performance of the Haifa
instruction scheduler vs. Sun's instruction scheduler.

Cheers,
Alex

Re: C++: EGCS perf. vs GCC

[Kurt Garloff]

On Tue, Dec 08, 1998 at 11:02:26AM +0000, Alex Maranda wrote:
> Will someone please enlighten me as for the purpose annd actual effect of
> -mcpu and -march? they are always both specified even if not passed

-mcpu turns on optimizations for the selected CPU (instruction scheduling
...) which don't destroy compatibility to the CPU specified with -march.
-march=pentiumpro eg. will result in binbaries which don't run on Pentiums,
486 ... using some PPro specific machine instructions.

-- 
+--------------------------------------------------------------+
|  cand.phys. Kurt Garloff        C1-O4-101 (Chemiegeb"aude)   |
|            garloff@hft.e-technik.uni-dortmund.de             |
|                 Public PGP key available !                   | 
+--------------------------------------------------------------+

Re: C++: EGCS perf. vs GCC

[Marc Lehmann]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1801 bytes --]

On Tue, Dec 08, 1998 at 10:35:16AM +0000, Alex Maranda wrote:
> -f<stuff> pack (you can see it when compiling with gcc -v -Q -O<optlevel>)
> and is my understanding that a greater <optlevel> is meant for speed. BTW,
> did you know there are undocumented levels -O4...-O8?

in PGCC, yes, in eGCS/GCC, no. BTW, -O3 already includes many optimizations
more than -O§ in EGCS.

On Tue, Dec 08, 1998 at 11:02:26AM +0000, Alex Maranda wrote:
> and =2. I will format the results in an intuitive way and post them
> tomorrow. It's enough to say now that pgcc went to warp by 3% vs. the best

If that are 3% in -O2 I think its quite respectable (if its with -O6 its
not). The only difefrences between egcs -O2 and pgcc -O2 are:

- no scheduling in pgcc
- a few small changes in the heuristics "to taste" in pgcc

It could be interesting to time these

-funroll-loops
-funroll-all-loops
-funroll-loops -fschedule-insns
-funroll-all-loops -fschedule-insns

with egcs, and, additionally with pgcc, "-O6 -frisc", "-O6 -fno-risc" (and
unrolling/no unrolling/scheduling)

You could also try -mk6 (or -mamdk6, dependent on version), I sometimes saw
interesting differences. Ah, and -mstack-align-double might change results
even more.

If you have success with any of these we have just another case where
optimizations slow down one program and speed up another. Its getting tricky.

      -----==-                                              |
      ----==-- _                                            |
      ---==---(_)__  __ ____  __       Marc Lehmann       +--
      --==---/ / _ \/ // /\ \/ /       pcg@goof.com       |e|
      -=====/_/_//_/\_,_/ /_/\_\                          --+
    The choice of a GNU generation                        |
                                                          |

Re: C++: EGCS perf. vs GCC

[Marc Lehmann]

On Mon, Dec 07, 1998 at 02:14:07PM -0500, John S. Dyson wrote:
> When playing with GCC, PGCC, and EGCS, it appears that the "good" optimization
> options for FP codes (on the X86) are not the same as for non-FP.  I guess that
> is to be expected because of the necessarily different code generator for 
> X86 FP.

I think its because there are "more" fp registers than integer registers.
Loop unrolling and scheduling (first pass) often help alot, while they are
detrimental in integer code.

It might be a good idea to try to selectively unroll and schedule fp-loops,
while not touching the integer loops. (This would keep me from saying "use
-funroll-all-loops and -fschedule-insns for fpu-intensive code only" ;)

Particularly interesting could be to add additional dependencies to integer
instructions in the first scheduling pass (like pgcc once did), so it
schedules fp-instructions automatically.

Also, loop-unrolling could become more selective on which loops to unroll
(best would be only the loops that need it ;->>>), but I can't really
imagine an heuristic for this, although I think the distinction between
-funroll-loops and -funroll-all-loops isn't helpful.

      -----==-                                              |
      ----==-- _                                            |
      ---==---(_)__  __ ____  __       Marc Lehmann       +--
      --==---/ / _ \/ // /\ \/ /       pcg@goof.com       |e|
      -=====/_/_//_/\_,_/ /_/\_\                          --+
    The choice of a GNU generation                        |
                                                          |

Re: C++: EGCS perf. vs GCC

[Alex Maranda]

> 
> add the following flags
> 
> -malign-double -malign-loops=0 -malign-jumps=0 -malign-functions=0 -fforce-mem 
> -fforce-addr 
> 
> 
> I've seen claims as much as 30% speedup.  There's also some controversy 
> as to whether the alignments should be =2 or not on the pentium chips (that's
> supposed to be optimal for the i486).

Last night, until an exceedingly late hour, I fed gcc/egcs/pgcc with these
new options (on top of the -f<stuff> turned on by -O3). I tried both =0
and =2. I will format the results in an intuitive way and post them
tomorrow. It's enough to say now that pgcc went to warp by 3% vs. the best
result from the initial posting; disappointing indeed, but the differences
between =0 and =2 will make an interesting reading.

Will someone please enlighten me as for the purpose annd actual effect of
-mcpu and -march? they are always both specified even if not passed
explicitely (gcc -v -Q will reveal that). My assumption is that -mcpu is
the target for which the code will be generated, and -march is the actual
target architecture which runs the code. The worst results are when you
mismatch them ignoring backward compatibility (i.e. -mcpu=pentiumpro
-march=pentium is much worse than -mcpu=i386 -march=pentium when run on a
PII). The sick part is that -mcpu=i386 -march=pentium is better than
-mcpu=pentiumpro -march=pentiumpro on a PII...

Cheers,
Alex

Re: C++: EGCS perf. vs GCC

[Alex Maranda]

> > Date: Mon, 7 Dec 1998 13:34:14 +0000 (GMT)
> > From: Alex Maranda <amaranda@spider.com>
> 
> > Multiple runs were performed for each combination, to average out
> > the variations induced by the OS scheduling The best result was
> > kept, as the standard deviation was very small.
> 
> I wouldn't use the term `average' to describe the selection of the
> `best' time.  When given, 10 11 12, average means 11, and `best' means
> 10.  It is confusing if you use both words.
You are definitely right, it is poor wording, but hopefully not procedure
:-) What I actually meant was: Initially I wanted to present the results
in a nice statistical form, averaging them and presenting also the
standard deviation. as the latter was very small (under 0.5%), I changed
my mind and chose the best result in each case - I suppose it is even more
relevant as I was trying to measure the compiler's instruction scheduler
performance, without taking into account the non-determinism introduced by
the OS task switching.

> 
> > -O3 -fno-rtti -mcpu=i386         46636    100          781263    100
> > -O3 -fno-rtti -mcpu=i486         50200    107.6        716301    91.6
> > -O3 -fno-rtti -mcpu=pentium      47392    101.6        777032    99.4
> > -O3 -fno-rtti -mcpu=pentiumpro   47344    101.5        725632    92.8
> 
> I'd try -fno-excetions, and -O2 and maybe even -O1.
I said I'm not using exceptions, I guess what you're implying is that even
so there is a constant overhead in the generated code which can be
eliminated by -fno-exceptions. I'll give it a try. The latter suggestions
don't make a lot of sense to me, each -Ox turns on an increasingly large
-f<stuff> pack (you can see it when compiling with gcc -v -Q -O<optlevel>)
and is my understanding that a greater <optlevel> is meant for speed. BTW,
did you know there are undocumented levels -O4...-O8?

Cheers,
Alex

Re: C++: EGCS perf. vs GCC

[Jeffrey A Law]

  In message < 199812071914.OAA06892@y.dyson.net >you write:
  > It seems that scheduling with the P6 is sometimes counter intuitive.
Scheduling in general can be counter intuitive :-)  I've spent most of the
last two weeks with my head buried in haifa pipeline dumps for a project I'm
working on.  

  > One can often gain significant performance improvements, but those
  > improvements are very sensitive to alignment and "pipeline" state.
Yes.  We've actually got most (all?) of the recommended stuff for PPro/PII
instruction alignments.   It was a small, but noticable win.  We've also made
significant improvments to data alignments, but more work needs to be done for
the data alignments, particularly stuff in the stack.


  I suggest reviewing
  > carefully:
  > 
  > 	http://www.announce.com/agner/assem
Yup.  Definitely worth the time for anyone that is interested in optimize
Pentium, PPro/PII.


jeff

Re: C++: EGCS perf. vs GCC

[John S. Dyson]

Jeffrey A Law said:
> 
>   > I understand there is a Pentium compiler around (pcc or something); will
>   > it do any difference? (or this is the stuff on which the Pentium support
>   > in gcc/egcs is based?)
> We are slowly, but surely moving the major features from pgcc into egcs.  Will
> pgcc help your code?  Maybe, maybe not.
                        ^^^^^^^^^^^^^^^^
> 
> 
>   > And finally, is Pentium II = Pentium Pro+MMX+better L2 cache? this why I
>   > hoped -mcpu=pentiumpro will unleash the demons living in my machine :-)
> My understanding is that from a scheduling standpoint PII == PPro.  So what
> you did makes sense.  The problem is the x86 port is just not designed to
> work with an instruction scheduler.  Thus performance when scheduling varies
> wildly.
> 
It seems that scheduling with the P6 is sometimes counter intuitive.  One
can often gain significant performance improvements, but those improvements
are very sensitive to alignment and "pipeline" state.  I suggest reviewing
carefully:

	http://www.announce.com/agner/assem

This is the most accurate and informative document that I have seen on X86
optimization.  There are older versions of that doc floating around, but the
1 Aug 98 version is fantastic.  It contains some info that I already knew, but
in a very clear and concise form -- and lots of info that I didn't already know.

I have played around with hand optimizing X86 (specifically P6) code, and it
is a "trip." :-).  IMO, on the P6, minimize partial register stalls (they are
really ugly -- however there are ways of repairing the damage), and be somewhat
careful about alignment.  It is also a good thing to unroll very short loops.
The normal kinds of scheduling don't seem to apply to the P6.  For almost any
floating point codes that I have played with, including circuit analysis and
transforms, I suggest not using omit frame pointer, and it is very important
to align doubles when possible.

When playing with GCC, PGCC, and EGCS, it appears that the "good" optimization
options for FP codes (on the X86) are not the same as for non-FP.  I guess that
is to be expected because of the necessarily different code generator for 
X86 FP.

-- 
John                  | Never try to teach a pig to sing,
dyson@iquest.net      | it makes one look stupid
jdyson@nc.com         | and it irritates the pig.

Re: C++: EGCS perf. vs GCC

[Alex Maranda]

please read below

Alex Maranda         mailto: amaranda@spider.com
Spider Software Ltd. Tel: +44 (0)131 4757036
Edinburgh, UK        http://members.xoom.com/Alex_Maranda
STREAMS based communications protocols for embedded systems

On Mon, 7 Dec 1998, Jeffrey A Law wrote:
> Good :-)  Both the ppro/pII and the old pentium scheduling need major changes;
> as does the entire machine description.  It's going to be a long slow process.
I've lived most of my life on SPARC, I had no idea gcc/egcs on x86 has
such serious problems. As for my network simulator, things can only get
better :-)

> We are slowly, but surely moving the major features from pgcc into egcs.  Will
> pgcc help your code?  Maybe, maybe not.
I am downloading pgcc1.1a as I write; thanks to everybody for the
plethora of options I've been flooded with :-). The next report will have
all three mighty compilers side by side, with those options on.

Perhaps I can help (hopefully nobody's laughing) with the evaluation of
the mods to be introduced in the x86 scheduler; I think my app has the
attributes required for a good scheduler meter, and it doesn't use
controversial semantics (templates, exceptions).

Cheers,
Alex

Re: C++: EGCS perf. vs GCC

[Jeffrey A Law]

  In message < Pine.GSO.3.96.981207163606.5165A-100000@caleyipa.spider.com >you w
  > Hmm, I have not used on the Intel architecture other compilers than gcc,
  > but I trust your judgement;
Good :-)  Both the ppro/pII and the old pentium scheduling need major changes;
as does the entire machine description.  It's going to be a long slow process.

  > processor was running at 248 Mhz), the part which I don't understand is
  > why -mcpu=pentiumpro is worse than -mcpu=i386 on a PII,
Could be anything.  There's no way to know without analyzing code.


  > and why gcc2.8.1 generates better code for i386 than egcs1.1.
Similarly.  It's a suprise, but it does happen from time to time.

  > I understand there is a Pentium compiler around (pcc or something); will
  > it do any difference? (or this is the stuff on which the Pentium support
  > in gcc/egcs is based?)
We are slowly, but surely moving the major features from pgcc into egcs.  Will
pgcc help your code?  Maybe, maybe not.


  > And finally, is Pentium II = Pentium Pro+MMX+better L2 cache? this why I
  > hoped -mcpu=pentiumpro will unleash the demons living in my machine :-)
My understanding is that from a scheduling standpoint PII == PPro.  So what
you did makes sense.  The problem is the x86 port is just not designed to
work with an instruction scheduler.  Thus performance when scheduling varies
wildly.

jeff

Re: C++: EGCS perf. vs GCC

[Alex Maranda]

> 
>   In message < Pine.GSO.3.96.981207132218.2689A-100000@caleyipa.spider.com >you w
> rite:
>   > 3. Compilers used
>   > 
>   > gcc 2.8.1
>   > egcs 1.1b (yes, I know 1.1.1 is out)
> I doubt egcs-1.1.1 would make any signficant difference performance-wise.  If
> it did, it would be by accident, not by design.
I've just downloaded 1.1.1; I'll have fresh figures in a couple of days.

> 
>   > i486 code, but other than that, the results are a complete surprise for me.
>   > I've expected that the proper use of the PII pipeline, etc. would boost the
>   > figures at least by 10%, and not degrade the performance!
> The scheduling for all x86 ports is poor at best.  It needs to be completely
> revamped from the ground up.
Hmm, I have not used on the Intel architecture other compilers than gcc,
but I trust your judgement; I am thrilled with the PII performance vs.
Ultra SPARC II performance for example (ok, I'm not fair here, the Ultra
processor was running at 248 Mhz), the part which I don't understand is
why -mcpu=pentiumpro is worse than -mcpu=i386 on a PII, and why gcc2.8.1
generates better code for i386 than egcs1.1.
I understand there is a Pentium compiler around (pcc or something); will
it do any difference? (or this is the stuff on which the Pentium support
in gcc/egcs is based?)
And finally, is Pentium II = Pentium Pro+MMX+better L2 cache? this why I
hoped -mcpu=pentiumpro will unleash the demons living in my machine :-)

PS: I will try the flags suggested by Gerhard Heinzel on both gcc2.8.1 and
egcs1.1.1 and strike again with an updated report :-)

Cheers,
Alex

Re: C++: EGCS perf. vs GCC

[Jeffrey A Law]

  In message < Pine.GSO.3.96.981207132218.2689A-100000@caleyipa.spider.com >you w
rite:
  > 3. Compilers used
  > 
  > gcc 2.8.1
  > egcs 1.1b (yes, I know 1.1.1 is out)
I doubt egcs-1.1.1 would make any signficant difference performance-wise.  If
it did, it would be by accident, not by design.

  > i486 code, but other than that, the results are a complete surprise for me.
  > I've expected that the proper use of the PII pipeline, etc. would boost the
  > figures at least by 10%, and not degrade the performance!
The scheduling for all x86 ports is poor at best.  It needs to be completely
revamped from the ground up.

jeff

C++: EGCS perf. vs GCC

[Alex Maranda]

C++: EGCS performance vs. GCC - myth or reality?
------------------------------------------------

Hi,
Please do not take the title of this posting as a flame intent; I have conducted
yesterday a suite of tests involving gcc and egcs which led to somewhat
confusing results (at least for me). I do not imply in any manner that the
results have any consistency whatsoever for other platforms/setups than the one
described below. I would like to share these results with you and get an expert
oppinion on these figures.

PS: please use also "Reply to author" as I haven't subscribed to any of these
mailing lists.

Cheers,
Alex Maranda

================================================================================

1. Software used for testing purposes

The application is a network simulator I wrote a couple of years ago, for which
I produced benchmarks on various architectures/operating systems. It is a
compute-bound program, which uses heavily the basic semantics of C++ (virtual
functions, multiple inheritance), but not the later additions to the language
(i.e. templates, exceptions). The particular simulation involved is the model
of an ATM statistical multiplexer which does negligible I/O.
All simulation runs had identical conditions, the only variables being the
compilers and the compiler flags. The performance was evaluated after the number
of events per second (ev/sec) processed; obviously, the higher the number, the
better the performance (and the shorter the running time). Timing is as accurate
as it can be, as the program uses gettimeofday(). Multiple runs were performed
for each combination, to average out the variations induced by the OS scheduling
The best result was kept, as the standard deviation was very small. 

2. Hardware/OS

Processor: PII/350 (genuine Intel)
RAM: 64 Mo (not critical because the app is not memory intensive)
OS: RedHat Linux 5.1

3. Compilers used

gcc 2.8.1
egcs 1.1b (yes, I know 1.1.1 is out)

libstdc++ was 2.8.0 for gcc and whatever the version is for egcs (the default
distribution). Shouldn't make any difference though as I'm barely using stuff
from there.

4. Results

gcc 2.8.1
--------------------------------------------------------------------------------
Compiler flags                   Exec. size             Speed
                                 (bytes)  (%)           (ev/sec)  (%)
--------------------------------------------------------------------------------
-O3 -fno-rtti -mcpu=i386         46636    100          781263    100
-O3 -fno-rtti -mcpu=i486         50200    107.6        716301    91.6
-O3 -fno-rtti -mcpu=pentium      47392    101.6        777032    99.4
-O3 -fno-rtti -mcpu=pentiumpro   47344    101.5        725632    92.8
--------------------------------------------------------------------------------


egcs 1.1b
--------------------------------------------------------------------------------
Compiler flags                   Exec. size             Speed
                                 (bytes)  (%)           (ev/sec)  (%)
--------------------------------------------------------------------------------
-O3 -fno-rtti -mcpu=i386         44712    100           745837    100
-O3 -fno-rtti -mcpu=i486         46056    103           774631    103.8
-O3 -fno-rtti -mcpu=pentium      45352    101.4         719423    96.4
-O3 -fno-rtti -mcpu=pentiumpro   45532    101.4         768135    103
--------------------------------------------------------------------------------


Now a speed comparison having the gcc 2.8.1-i386 result as base:
--------------------------------------------------------------------------------
target arch.        gcc 2.8.1 (%)         egcs 1.1b (%)
--------------------------------------------------------------------------------
i386                100                   95.4
i486                94.3                  99.1
pentium             99.4                  92
pentiumpro          92.8                  98.3
--------------------------------------------------------------------------------


4. Conclusions (mine :-)

As a general comment, Pentium II is one hell of a processor; the same benchmark
run on a Sparc Ultra 30/SPARC Ultra II/248 mhz/Solaris 2.6 machine would not
yield more than 530000 ev/sec. More to the point, the above results are
worrying, at least for the Intel instructions scheduler (I understand the RISC
targets use in egcs the Haifa instructions scheduler).
I will state now the obvious, which is gcc 2.8.1 - i386 is best when run on PII!
I recall a posting which said that Pentium is better than Pentium II at running
i486 code, but other than that, the results are a complete surprise for me.
I've expected that the proper use of the PII pipeline, etc. would boost the
figures at least by 10%, and not degrade the performance!
Either I'm doing something terribly wrong (and if so please spot my error!) or
the Pentium scheduler is not doing the job properly.

5. Conclusions (yours :-)
...

Alex Maranda         mailto: amaranda@spider.com
Spider Software Ltd. Tel: +44 (0)131 4757036
Edinburgh, UK        http://members.xoom.com/Alex_Maranda
STREAMS based communications protocols for embedded systems