From owner-freebsd-stable Fri Oct 27 0:28:48 2000 Delivered-To: freebsd-stable@freebsd.org Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by hub.freebsd.org (Postfix) with ESMTP id 8CCFE37B479 for ; Fri, 27 Oct 2000 00:28:43 -0700 (PDT) Received: from parthe.lpthe.jussieu.fr (parthe.lpthe.jussieu.fr [134.157.10.1]) by shiva.jussieu.fr (8.10.0/jtpda-5.3.3) with ESMTP id e9R7Sgq45534 for ; Fri, 27 Oct 2000 09:28:42 +0200 (CEST) Received: from rose.lpthe.jussieu.fr ([134.157.10.102]) by parthe.lpthe.jussieu.fr (8.9.1a/jtpda-5.3.1) with ESMTP id JAA03220 for ; Fri, 27 Oct 2000 09:28:41 +0200 (MET DST) Received: (from michel@localhost) by rose.lpthe.jussieu.fr (8.9.3/8.9.3) id JAA00457 for freebsd-stable@FreeBSD.ORG; Fri, 27 Oct 2000 09:28:41 +0200 (CEST) (envelope-from michel) Date: Fri, 27 Oct 2000 09:28:41 +0200 From: Michel Talon To: "freebsd-stable@FreeBSD.ORG" Subject: Re: "Malloc type lacks magic" show-stopper solved Message-ID: <20001027092841.B394@lpthe.jussieu.fr> Mail-Followup-To: "freebsd-stable@FreeBSD.ORG" References: <20001026231134.D9391@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Oct 27, 2000 at 07:17:09PM +1300, Juha Saarinen wrote: > > Then you were using GCC 2.7.2 in FreeBSD 3.3 -- a very different animal > > than 2.95.2. > > Yes, it is, but recall building 2.95.2 from the ports collection and using > that instead. > > > WHY!?!?!? Just what the heck do you think you're achieving with -O3 plus > > all those things? Have you *ever* profiled anything you're compiling > > with these options? Note that -O3 is not necessarily faster code than -O. > > > > This seems Yet Another "I'm macho" compiler flags instance. > > Please correct me if I'm wrong. > > Entirely possible -- but, if you don't try it, you'll never know... ;-) > > I thought I'd try, because anecdotal evidence suggested that the > optimisations made a performance difference (a positive one, that is). If > you have profiled and benchmarked code with no opts and compared it to > code compiled with optimisations, I'd be interested to see the results. I > mean, if there's no point, I'd like to know so that I can stop wasting > time fiddling with these things... ;-) Kernel code is simple with essentially no computations (except of course special domains like crypto in kernel). So there is no much room for optimizations. Recently i have timed a scientific program to see the performances of my brand new PC. Here is what i found: Without any optimization the program runs 2 times slower. With -O -O2 -O3 -Os the times are similar, the fastest was -O the slowest was -Os. Since my PC is Duron based i have tried -march things, and have compared on a pentium machine. Result, almost nothing, except -march pentium was slower than -march k6 on the Duron as could be expected. All differences are small, no more than 2s on a 30s computation. As you can see nothing that counterbalances the risk of bugs. More generally, gcc does not output specialized instructions like 3dNow and so on. These have to be hand coded in assembly if you want them. An exemple is the mp3 compressor gogo which is coded in assembly and has to be compiled with nasm because gas is not even able to understand these instructions. So don't think you can obtain something well optimized with gcc. To illustrate this, i have some years ago tested a scientific program on an alpha machine running linux. Compiled with gcc and the best optimizations it runned 7 times slower than compiled with Digital compiler. Conclude by yourself. -- Michel Talon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message