Mail Archives: pgcc/1998/06/07/20:32:13
Krzysztof, could you please fix your mail? Every third mail I sent to you bounces!
----- Forwarded message from Mail Delivery Subsystem <MaiLER-DaemON AT de DOT UU DOT NET> -----
Received: from root by cerebro with local (Exim 1.92 #2)
for marc AT laendle
id 0yilpq-0000tm-00; Sun, 7 Jun 1998 22:14:34 +0200
X-pop3-spooler: POP3MAIL 2.1.0 b 4 980420 -bs-
Received: from goof.com (goof.com [128.173.247.211]:4839)
by binky.de.uu.net with SMTP (5.65+:003/3.0.2)
id WAA18027; Sun, 7 Jun 1998 22:01:08 +0200 (MET DST)
Received: (qmail 10425 invoked by uid 15017); 7 Jun 1998 20:03:19 -0000
Received: (qmail 10419 invoked from network); 7 Jun 1998 20:03:18 -0000
Received: from binky.de.uu.net (192.76.144.28)
by goof.com with SMTP; 7 Jun 1998 20:03:18 -0000
Date: Sun, 7 Jun 1998 22:00:22 +0200 (MET DST)
From: Mail Delivery Subsystem <MaiLER-DaemON AT de DOT UU DOT NET>
Message-Id: <199806072000 DOT WAA08657 AT binky DOT de DOT uu DOT net>
Received: from localhost (localhost:)
by binky.de.uu.net with internal (5.65+:003/3.0.2)
id WAA08657; Sun, 7 Jun 1998 22:00:22 +0200 (MET DST)
To: <pcg AT goof DOT com>
Precedence: junk
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
boundary="WAA08657.897249622/binky.de.uu.net"
Subject: Returned mail: Cannot send message within 5 days
Auto-Submitted: auto-generated (failure)
Sender: Marc Lehmann <pcg AT goof DOT com>
This is a MIME-encapsulated message
--WAA08657.897249622/binky.de.uu.net
The original message was received at Tue, 2 Jun 1998 21:54:04 +0200 (MET DST)
from pec-17.au1.ka.uunet.de [149.228.138.17]
----- The following addresses had permanent fatal errors -----
<strasbur AT chkw386 DOT ch DOT pwr DOT wroc DOT pl>
----- Transcript of session follows -----
451 <strasbur AT chkw386 DOT ch DOT pwr DOT wroc DOT pl>... reply: read error from chkw386.ch.pwr.wroc.pl.
<strasbur AT chkw386 DOT ch DOT pwr DOT wroc DOT pl>... Deferred: Connection reset by chkw386.ch.pwr.wroc.pl.
Message could not be delivered for 5 days
Message will be deleted from queue
--WAA08657.897249622/binky.de.uu.net
Content-Type: message/delivery-status
Reporting-MTA: dns; binky.de.uu.net
Arrival-Date: Tue, 2 Jun 1998 21:54:04 +0200 (MET DST)
Final-Recipient: rfc822; strasbur AT chkw386 DOT ch DOT pwr DOT wroc DOT pl
Action: failed
Status: 4.4.7
Remote-MTA: dns; chkw386.ch.pwr.wroc.pl
Last-Attempt-Date: Sun, 7 Jun 1998 22:00:21 +0200 (MET DST)
--WAA08657.897249622/binky.de.uu.net
Content-Type: message/rfc822
Return-Path: <pcg AT goof DOT com>
Received: from cerebro (pec-17.au1.ka.uunet.de [149.228.138.17]:1081)
by binky.de.uu.net with ESMTP (5.65+:003/3.0.2)
for chkw386.ch.pwr.wroc.pl
id VAA14686; Tue, 2 Jun 1998 21:54:04 +0200 (MET DST)
Received: from root by cerebro with local (Exim 1.92 #2)
for strasbur AT chkw386 DOT ch DOT pwr DOT wroc DOT pl
id 0ygsYI-0000SA-00; Tue, 2 Jun 1998 17:00:38 +0200
Message-ID: <19980602170037 DOT 43672 AT cerebro DOT laendle>
Date: Tue, 2 Jun 1998 17:00:37 +0200
From: Marc Lehmann <pcg AT goof DOT com>
To: Krzysztof Strasburger <strasbur AT chkw386 DOT ch DOT pwr DOT wroc DOT pl>
Subject: Re: Executable sizes and performance
References: <m0ygr45-000203C AT chkw386 DOT ch DOT pwr DOT wroc DOT pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <m0ygr45-000203C AT chkw386 DOT ch DOT pwr DOT wroc DOT pl>; from Krzysztof Strasburger on Tue, Jun 02, 1998 at 01:25:00PM +0000
X-Operating-System: Linux version 2.1.103 (root AT cerebro) (gcc version pgcc-2.91.30 19980524 (gcc2 ss-980502 experimental))
On Tue, Jun 02, 1998 at 01:25:00PM +0000, Krzysztof Strasburger wrote:
>
> Here is the comparison of executable sizes and execution times of the old
Thanks.
> Some general conclusions (valid only for FPU intensive, f2c translated
I like these.
> code, of course):
> 1. Old gcc (2.7.2.3) gives smaller executables even with double aligning of
> "double precision" variables.
I will remove the (outdated) reference to pgcc giving smaller executables
from the FAQ.
> 2. This data aligning is critical for the efficiency of the code (as pointed
> out in the pgcc FAQ). Look at column 5. On the other hand, programs
> which are not CPU intensive could be compiled with these options plus
> -fno-strength-reduce (gcc 2.7.2.3 of course). You will get small
> executables - smaller than with egcs/pgcc.
-fno-strength-reduce might be a candidate for -Os, then.
> 3. It is not true, that old pgcc (2.7.2 based) gives faster code than the
> new one. In some cases it can be even slower than the code produced by
> gcc 2.7.2.3 with -malign-double.
Thats fine. But there was a period where this was true. Fortunately,
improvements in egcs compensated for the speed-due-to-stability-loss.
> 4. The haifa scheduler does not give more efficient code (columns 3 and 4)
It still needs to be tuned ;(
> 5. Code aligning is meaningless. Compare columns 3 and 6. Maybe the Big Theory
> of Programming says "it is the most important thing for performance".
> I got code bloat only.
Only on pentiums. The pentium indeed doesn't care for alignment (although 2
should be worse than either 4 or 0). In most cases, the speed increase
gained by aligned jumps/loops is compensated by the nops introduced.
> 6. The -fstrength-reduce thing gives code bloat, but the performance
> is slightly better (column 3 without and 7 with -fno-strength-reduce).
the strength reduction is necessary for loop unrolling, which gives _large_
code bloat, but also much higher speed, esp. for fpu-intensive code. It also
creates very high register pressure, which is bad since gcc can't cope with
a small register set.
> 7. There is no single optimal set of compilation options for all code.
> There are execution paths, where other variants run faster than 3 (which
> is best in general).
Thats why we need more profile-based optimizations, i.e. _measure_ how often
which paths are taken and optimize accoridng to this information.
>
> I will made similar comparison for a program, which doesn't use the FPU.
> Bzip2 seems to be the good candidate.
And gzip without the assembler functions ;) btw, bzip2 uses vast amounts of
memory (bad for the cache), so it might be better to use low (-1)
compression. (well, these are only quick guesses)
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / pcg AT goof DOT com |e|
-=====/_/_//_/\_,_/ /_/\_\ --+
The choice of a GNU generation |
|
--WAA08657.897249622/binky.de.uu.net--
----- End forwarded message -----
WARNING: I'm in my monthly flame phase this month.
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / pcg AT goof DOT com |e|
-=====/_/_//_/\_,_/ /_/\_\ --+
The choice of a GNU generation |
|
- Raw text -