From owner-freebsd-stable@FreeBSD.ORG Tue Nov 8 03:58:24 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 886BB16A41F for ; Tue, 8 Nov 2005 03:58:24 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B41743D45 for ; Tue, 8 Nov 2005 03:58:23 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id 1B9425D69; Mon, 7 Nov 2005 22:58:23 -0500 (EST) Received: from pi.codefab.com ([127.0.0.1]) by localhost (pi.codefab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25349-10; Mon, 7 Nov 2005 22:58:21 -0500 (EST) Received: from [192.168.1.3] (pool-68-161-122-227.ny325.east.verizon.net [68.161.122.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pi.codefab.com (Postfix) with ESMTP id BD9F45C20; Mon, 7 Nov 2005 22:58:20 -0500 (EST) Message-ID: <4370225D.2070201@mac.com> Date: Mon, 07 Nov 2005 22:58:21 -0500 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Craig Boston References: <20051107151050.GA1212@nowhere> <200511080205.jA825Dbl046080@app.auscert.org.au> <20051108032328.GA3544@nowhere> In-Reply-To: <20051108032328.GA3544@nowhere> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at codefab.com Cc: freebsd-stable@freebsd.org Subject: Re: 5.x, 6.x and CPUTYPE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2005 03:58:24 -0000 Craig Boston wrote: > On Tue, Nov 08, 2005 at 12:05:13PM +1000, Joel Hatton wrote: >> Thanks, Craig. I'm glad to hear that I'm not alone in pursuing this method. >> Do you know of any particular disadvantages of continuing with this >> less-than-optimised model - I guess I mean, is this something that is >> likely to break or become uneconomical at some point? > > It won't break; after all the release binaries are targeted for 386 (or > maybe 486 now) in order to be able to run on anything. You might need > to update make.conf with the "pentiumpro" name just in case they ever > drop the i686 alias, but that's about it. Yes. Note that you should choose the lowest common denominator for the hardware you possibly might want to run the binaries on. "pentium" or "pentiumpro" are also good candidates in that they are well-tested targets compared with the p4 or Althon targets. > You might not get quite as good performance as if you compiled for > exactly your CPU (keep in mind we're probably talking about 1-2% at most > unless you have a VERY specific workload that SSE could benefit), but > IMO it's more than worth it to be able to plug the hard drives into a > similar machine and have things Just Work. Agreed, although the performance difference depends a lot on the tasks being done. Disabling the "cpu I386_CPU" statement in the kernel conf seems to be more important than the difference between specifying a compiler architecture or leaving it to the default. > Personally, I pick i686 (pentiumpro) as a good middle ground. The > features optimized for by that are present in every modern > x86-architecture CPU: P2, P3, P4, Athlon, etc. So it's unlikely you'll > run into something older than that. Also, the ppro has most of the > features that really affect performance -- i.e. the gap between 386/486 > and 686 is a lot bigger than the gap between 686 and P3/P4. Agreed. The gap in performance is 386/486 >> 486/586 > later models. > P3s/P-M and Athlons especially are fairly smart and will optimize a lot > of things at runtime. P4s are probably where you'll see the biggest > performance hit -- that's where Intel tried to push a lot off it off on > the compiler. The P4 can benefit significantly sometimes from a compiler that knows how to schedule for it and the underlying microcode which actually implements the x86 instructions, rather than just for a generic pentium, but most of the time there isn't much difference between using "pentium" and "pentium4". -- -Chuck