Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
From: "Dockeen" <dockeen AT mchsi DOT com>
To: <cygwin AT cygwin DOT com>
Subject: Re: gcc3.2 vs gcc2.95 - devolution never stops
Date: Thu, 29 Aug 2002 22:12:31 -0300
Message-ID: <NCBBLKKJGBJOLDFMCKFPCENHCAAA.dockeen@mchsi.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000

I think I mumbled something about this a few months ago.
I found that the execution speed for an imaging program
that we work on in our shop went up by a noticable amount,
anywhere from 15% - 25%

Because I am not compiling a ton of SLOC, the increased 
compile time was not a big deal.  I can see (and have 
read) where it is for people pushing a lot of SLOC.

One nice thing about the 3.1+ family of gcc is that you
can set flags for optimization for the P3 and P4 processors.
(Yep, Intel around our shop).  This helps the speed.

The code passed my regression testing...

The increased exe file size was there, stripping brought it 
back close to where it was before.

Have a good night,

Wayne Keen

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/