www.delorie.com/archives/browse.cgi   search  
Mail Archives: pgcc/1998/09/03/09:16:54

X-pop3-spooler: POP3MAIL 2.1.0 b 4 980420 -bs-
Message-Id: <m0zEVDC-0000FVC@chkw386.ch.pwr.wroc.pl>
Date: Thu, 3 Sep 98 08:57
From: strasbur AT chkw386 DOT ch DOT pwr DOT wroc DOT pl (Krzysztof Strasburger)
To: pcg AT goof DOT com, strasbur AT chkw386 DOT ch DOT pwr DOT wroc DOT pl
Subject: Re: pgcc-1.1a - first impression
Cc: beastium-list AT desk DOT nl
Sender: Marc Lehmann <pcg AT goof DOT com>
Status: RO
X-Status: A
Lines: 42

>> The first thing I noticed is code bloat :-(, but this is rather egcs
>Does -fno-exceptions help?
No. Anyway, my executables are linked with the old libgcc.a (2.7.2.3).
>> [no speed improvement on pentium]
>Thats, erhm, bad. But did you try -O6, as the most effective optimization
>on pentiums is enabled with -O5 and higher only.
-O6 and -O5 give identical code. It is really fast. Great!
Previous pgcc gave nothing besides code bloat.

These results have been obtained on Pentium 133. Pgcc uses the old
instruction scheduler (no Haifa).

Optimization       pgcc-1.0.3a                pgcc-1.1a
  level       executable  execution     executable  execution
                 size       times          size       times
   -O2          46632       39.39s        48072       39.75s
   -O3          46968       38.94s        48488       39.29s
   -O4          48056       38.97s        49384       39.15s
   -O5          52888       39.60s        54152       37.89s
   -Os            -           -           47080       39.24s
 gcc-2.7.2.3 -m486 -O2 -malign-double
                45472       42.42s
 pgcc-1.1a -Os without double aligning
                46664       39.42s
>Having said this, I have no idea what could have happened to pentium opts,
>as I can't remember changing them significantly ;( But the performance
>problems in egcs/pgcc I talked about in my earlier mail is mainly related to
>fpu-intensive programs...
Well, optimizations below -O5 give really slower code than with pgcc-1.0.3a.

>Could you try without the *align-double options? (just a guess) And maybe
>you could post your benchmark data with -O2,3,6?
See above. There is no big speed difference between executables with
and without double aligning, because almost all data are
allocated by malloc() and properly aligned. I found that this program is
pretty immune against optimizations - maybe because the most critical
code is split in short functions. The 10% speedup against the old
gcc is very good result. 

>Thanks,
Thanks for the compiler, I couldn't post these tests without it!
Krzysztof

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019