Date: Fri, 27 Oct 2000 06:36:58 -0700 (PDT) From: Glendon Gross <gross@clones.com> To: Michel Talon <michel@lpthe.jussieu.fr> Cc: "freebsd-stable@FreeBSD.ORG" <freebsd-stable@FreeBSD.ORG> Subject: Re: "Malloc type lacks magic" show-stopper solved Message-ID: <Pine.LNX.4.20.0010270634450.6309-100000@mail.clones.com> In-Reply-To: <20001027092841.B394@lpthe.jussieu.fr>
next in thread | previous in thread | raw e-mail | index | archive | help
This reminds me of another issue I have wondered about for some time. Are there major advantages to be gained by disabling support for other architectures in the kernel build file? I have been routinely turning off 386 and 486 support, thinking this would speed things up... but I'm not sure of the soundness of this logic. Does anyone know if disabling support for other CPU's increases performance? On Fri, 27 Oct 2000, Michel Talon wrote: > 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 > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.20.0010270634450.6309-100000>