From owner-freebsd-current@FreeBSD.ORG Wed Jan 21 10:14:28 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8134E16A4CE for ; Wed, 21 Jan 2004 10:14:28 -0800 (PST) Received: from mail1.speakeasy.net (mail1.speakeasy.net [216.254.0.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id B343A43D46 for ; Wed, 21 Jan 2004 10:14:14 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: (qmail 16018 invoked from network); 21 Jan 2004 18:14:14 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 21 Jan 2004 18:14:14 -0000 Received: from 10.50.40.205 (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.10/8.12.10) with ESMTP id i0LIDxM8019746; Wed, 21 Jan 2004 13:14:10 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Bruce Evans Date: Wed, 21 Jan 2004 11:04:49 -0500 User-Agent: KMail/1.5.4 References: <200401190738.i0J7ccF3020266@postoffice.e-easy.com.au> <200401201319.52943.jhb@FreeBSD.org> <20040121153615.O7322@gamplex.bde.org> In-Reply-To: <20040121153615.O7322@gamplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401211104.49878.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: freebsd-current@FreeBSD.org cc: Ruslan Ermilov Subject: Re: Release Building and /etc/make.conf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2004 18:14:28 -0000 On Tuesday 20 January 2004 11:58 pm, Bruce Evans wrote: > On Tue, 20 Jan 2004, John Baldwin wrote: > > On Tuesday 20 January 2004 09:41 am, Bruce Evans wrote: > > > bsd.cpu.mk should rarely be edited, but /etc.make.conf is per-machine > > > so you can put anything you want in it. However, defaulting to > > > -mcpu=pentiumpro is just a bug, so I edit it out of bsd.cpu.mk. It > > > just micro-pessimizes for all CPUs that aren't pentium pros. This is > > > almost harmless for i386's because no one uses them, and almost > > > harmless for P3's and maybe P4's because they share some bottlenecks > > > with pentiumpros, but Athlons handle naive i386 code better than > > > pentiums so many of the pentiumpro optimizations are pessimizations for > > > athlons. > > > > The choice if ppro was Peter's suggestion. Feel free to offer a better > > default CPU to tune for. > > i386 (or equivalently, no special tuning) is the best default, at least > in non-FPU-intensive applications. In my integer crunching application/ > benchmark (searching a game tree), it even gives better results than > -mcpu=pentiumpro on a pentiumpro class machine (a 366MHz Celeron). > -mcpu=athlon-xp gives even better results. > > All with -O3 -fomit-frame-pointer > -mcpu-athlon-xp 48.42 real 47.31 user 0.41 sys > 51.22 real 50.10 user 0.30 sys > -mcpu=i386 51.98 real 50.18 user 0.34 sys > -mcpu=pentiumpro 56.38 real 55.26 user 0.34 sys > -mcpu=pentium2 56.24 real 55.25 user 0.36 sys > -mcpu=pentium3 56.59 real 55.25 user 0.40 sys > -mcpu=pentium4 58.52 real 56.96 user 0.36 sys > -mcpu=i486 79.17 real 77.69 user 0.32 sys > -mcpu=i586 74.80 real 73.07 user 0.48 sys > > This is just one benchmark, chosen for its potential optimizability. > I only did non-exhaustive benchmarks for the makeworld benchmark. I > removed the -mpentiumpro change when I saw the kernel size bloat that > it gave. Does -mcpu=althon-xp perform worse than the default in other benchmarks that you've run? > > > Note that CPUTYPE has worse bugs for i386's. Setting it to a supported > > > CPU gives -march instead of -mcpu, so using it gives unportable > > > binaries, and bsd.cpu.mk provides no way to get the corresponding -mcpu > > > settings. OTOH, CPUTYPE for alphas gives only -mcpu. > > > > That is by design. Note that on all non-i386 architectures such as > > alpha, etc. -mcpu means the same thing as -march. The other > > architectures use -mtune to get the same effect as -mcpu on i386. > > Doesn't make it any less of a bug. The intent of CPUTYPE is that you can have ports and world optimized for the specific machine you are compiling on, it is not set to anything by default, so the user only gets -march=foo if they explicitly ask for it. I fail to see how that is a bug. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org