From mint-bounce@lists.fishpool.fi Sun Feb 10 13:27:21 2008 From: Eero Tamminen Organization: Koti To: mint@lists.fishpool.fi Subject: Re: [MiNT] Binutils 2.18 + GCC 4.2.3 Date: Sun, 10 Feb 2008 20:23:42 +0200 User-Agent: KMail/1.9.6 Cc: MiKRO , "Keith Scroggins" , mint References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200802102023.42973.oak@helsinkinet.fi> X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: oak@helsinkinet.fi Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: List-subscribe: List-owner: List-post: Hi, On Saturday 09 February 2008, MiKRO wrote: > > would be to bootstrap the compiler with the new 060 multilib, and then > > pass the -m68060 parameter doing a rebuild (with --disable-bootstrap to > > configure), and let it die when it gets to the lib parts, which should > > be after executables are already produced. BTW, I tried -O3 and it > > increases > > Hmm, yes, this could be worth of trying.. I'll try it then :) > > > the size of cc1 and cc1plus about 1 meg each, that size increase makes > > me think its more harm done than the speed increase. Just sharing. > > not necessarily -- -O3 could mean some stuff got unrolled for example. > Maybe you could try some measuring, if we got 10% speedup for example, > this would be cool, one meg plus minus. This unrolling often makes the code too large to fit into CPU caches and then code actually gets slower. IMHO the only reasonable way to use -O3 is to measure the speed (in addition to size change :-)), and maybe use it only for some specific *.c files which one has found to be problematic when profiling.... - Eero