From owner-freebsd-current@FreeBSD.ORG Wed Jun 6 22:45:07 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 88DD316A469 for ; Wed, 6 Jun 2007 22:45:07 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by mx1.freebsd.org (Postfix) with ESMTP id 68CCB13C455 for ; Wed, 6 Jun 2007 22:45:07 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from hymn01.u.washington.edu (hymn01.u.washington.edu [140.142.8.55]) by mxout4.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.05) with ESMTP id l56Mj6s1014003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 6 Jun 2007 15:45:07 -0700 Received: from localhost (localhost [127.0.0.1]) by hymn01.u.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l56Mj6iE032684 for ; Wed, 6 Jun 2007 15:45:06 -0700 X-Auth-Received: from [192.55.52.3] by hymn01.u.washington.edu via HTTP; Wed, 06 Jun 2007 15:45:06 PDT Date: Wed, 6 Jun 2007 15:45:06 -0700 (PDT) From: youshi10@u.washington.edu To: current@freebsd.org In-Reply-To: <200706061612.l56GCnYc097589@ambrisko.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.3.1.294258, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.6.6.152833 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='SUPERLONG_LINE 0.05, NO_REAL_NAME 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' Cc: Subject: Re: Intel C2D COREs not used equally in FreeBSD 7.0-CURRENT i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Jun 2007 22:45:07 -0000 On Wed, 6 Jun 2007, Doug Ambrisko wrote: > Dag-Erling Sm\xc3\xb8rgrav writes: > | Oliver Fromme writes: > | > It's a common mistake to assume that amd64 only makes sense > | > if you have >= 4GB RAM. There are several reasons why it > | > might be useful to switch from i386 to amd64: > | > > | > - Most programs (though not all) will run faster, because > | > in amd64 mode there are twice as many general-purpose > | > registers, giving compilers much better opportunities > | > for optimizations and caching of values, and reducing > | > slow memory accesses. > | > | "twice as many" is an understatement. AMD64 has 16 GPRs vs i386's 8 if > | you consider BP, SI, DI and SP as GPRs (as the AMD and Intel literature > | does); in practical terms the score is 12 to 4. > | > | > - Some applications might benefit from a larger virtual > | > address space > 4 GB. (Note that this is not related > | > to the amount of physical RAM!) > | > | For instance, Varnish maps its entire storage into memory, and will > | benefit greatly from the increased address space. > | > | > In practice there's (almost) only one reason not to run > | > FreeBSD/amd64 on amd64-capable hardware: If you depend > | > on a certain piece of software which is known not to run > | > correctly in 64bit mode. Fortunately those are not many. > | > | The only one I can think of (for a desktop) is the Flash plugin. > > Why? With the nspluginwrapper we can running Linux Flash in a FreeBSD > native browser on amd64 or i386. With the appropriate compile foo > or probably by getting a Linux compiled version it would work with > a Linux browser. Nspluginwrapper is great for running i386 plugins > on amd64! > > The only thing that is preventing me from running full time on an > amd64 kernel is the kernel support for suspend & resume. I had to > add a small hack the kernel to let the i386 Xserver to run on amd64. > I need to do some more digging to answer some questions that alc had. > > Personally, I want to run amd64 full time so I can run and build amd64 > and i386 things on my laptop without rebooting at native speed. > > Doug A. If things are setup properly with 32-/64-bit lib profiling, there should be little issue with things, unless it's dealing with kernel level drivers (i.e. nvidia-drivers, etc). This should be true not just for nspluginwrapper, but also programs like win32-codecs, and the like, so long as the paths aren't incorrectly hardcoded when linked in the codec (haven't come across that though). Of course you probably won't see a big performance boost for any 64-bit architectures in the codecs (SSE3, SSE4 for Intel and whatever AMD's using for their specialized FP stuff), but that's true for Windows machines as well. -Garrett