From owner-freebsd-hardware@FreeBSD.ORG Mon Dec 29 21:42:29 2003 Return-Path: Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D80CE16A4CE for ; Mon, 29 Dec 2003 21:42:29 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id ADF5443D49 for ; Mon, 29 Dec 2003 21:42:26 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id QAA14289; Tue, 30 Dec 2003 16:42:17 +1100 Date: Tue, 30 Dec 2003 16:42:16 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Matt Staroscik In-Reply-To: <6412.207.46.125.17.1072729575.squirrel@wrongcrowd.com> Message-ID: <20031230155146.D6269@gamplex.bde.org> References: <20031229200107.4D80916A4D9@hub.freebsd.org> <6412.207.46.125.17.1072729575.squirrel@wrongcrowd.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hardware@freebsd.org Subject: Re: Kernel Optimizations for Processors (Now AthlonXP Q) X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Dec 2003 05:42:30 -0000 On Mon, 29 Dec 2003, Matt Staroscik wrote: > A while back I did a big Google session to try and find the best kernel > and make flags for the AthlonXP proc (under FreeBSD 4.x). At the time, > most of what I read said that the AthlonXP did best with (make.conf) > CPUTYPE=i686, and the k7 flag just fell back to something like that anyway > because there wasn't complete support for it yet in the compiler. gcc-3.x in -current has direct support for AthlonXP. This may be worth a few percent in a few applications (the largest I saw was 11% for an integer-crunching application (searching a game tree)). CPUTYPE=i686 is about the worst possible for Athlons. It mostly gives extra instructions to avoid using some 386 instructions that PentiumPros handle poorly. Athlons handle these instructions well so CPUTYPE=i686 mainly just gives extra overheads for executing the extra instructions. The effects of this are quite small (something more like -0.1% than 11%). Setting CPUTYPE also affects things other than gcc (mainly a few applications that have special assembler support for to give very MD optimizations). I haven't benchmarked any of these. The best optimizations may involve using SSE, but RELENG_4 doesn't support this in userland for athlons (CPUTYPE=k7 gives only `MACHINE_CPU = k7 3dnow mmx k6 k5 i586 i486 i386', while CPUTYPE=athlon-xp in -current also gives athlon-xp and sse in MACHINE_CPU). RELENG_4 doesn't really support SSE in the kernel either (signals may trash the SSE state), so it mostly shouldn't be used. > Likewise > my kernel is set to: > > cpu I686_CPU > > Is this advice still valid, if it ever was? Can anyone comment on the best > make & kernel options for the AthlonXP CPU? Setting I686_CPU mainly prevents gratuitous refusing to boot i686 and later CPUs. The Ix86_CPU options are mostly bugs. This is mostly fixed for later CPUs by not using these options to determine features or break booting of old kernels on new CPUs. Things are handled better using the cpuid instruction to determine features. Anyway, these options only control a couple of performance-related features. Configuring I386_CPU forces use of i386-only instructions in a few not very important places in RELENG_4 (this is more harmful for real i686's). Configuring I386_CPU in -current forces use of i386-only instructions in a many important places, so it is much more harmful and not to default (but still costs only a few percent overall). I just always use I486_CPU, I586_CPU and I686_CPU (configuring them all costs epsilon), and make gcc optimize for 386's by not setting CPUTYPE and editing out the harmful default setting of -mcpu=pentiumpro in bsd.cpu.mk (this bug is only in -current). Bruce