X-pop3-spooler: POP3MAIL 2.1.0 b 4 980420 -bs- Message-ID: <19980607221607.34783@cerebro.laendle> Date: Sun, 7 Jun 1998 22:16:07 +0200 From: Marc Lehmann To: beastium Subject: [MaiLER-DaemON AT de DOT UU DOT NET: Returned mail: Cannot send message within 5 days] Mail-Followup-To: beastium Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Operating-System: Linux version 2.1.104 (root AT cerebro) (gcc version pgcc-2.91.34 19980530 (gcc2 ss-980502 experimental)) Status: RO Content-Length: 7105 Lines: 167 Krzysztof, could you please fix your mail? Every third mail I sent to you bounces! ----- Forwarded message from Mail Delivery Subsystem ----- 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 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: 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 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 ----- ----- Transcript of session follows ----- 451 ... reply: read error from chkw386.ch.pwr.wroc.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: 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 To: Krzysztof Strasburger Subject: Re: Executable sizes and performance References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: ; 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 | |