From owner-freebsd-amd64@FreeBSD.ORG Fri May 13 19:51:18 2005 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7137216A4CE for ; Fri, 13 May 2005 19:51:18 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id B660543D54 for ; Fri, 13 May 2005 19:51:15 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [127.0.0.1] ([168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j4DJtQ02055425; Fri, 13 May 2005 13:55:26 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4285050F.7000202@samsco.org> Date: Fri, 13 May 2005 13:50:39 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Jo=E3o_Carlos_Mendes_Lu=EDs?= References: <42842F46.9040608@samsco.org> <4284FD37.2070009@jonny.eng.br> In-Reply-To: <4284FD37.2070009@jonny.eng.br> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org cc: Michael Hopkins cc: "freebsd-amd64@freebsd.org" Subject: Re: Actual benefits of amd64 over i386 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2005 19:51:18 -0000 João Carlos Mendes Luís wrote: > Scott Long wrote: > >>Michael Hopkins wrote: >> >>>Hi all >>> >>>I have been suffering quite a bit of frustration recently with many ports >>>that I need being 'i386 only' and no straightforward fixes. Maybe amd64 >>>could be described as 'tier 1.5' ;o) >>> >>>Can I ask for honest opinions here on what speed (or other?) benefits I >>>should get by running amd64 over i386? I will never be using more than >>>about 1 G of memory on this particular machine so memory limit is not an >>>issue. Maybe I should just rebuild the machine as i386? >>> >>>It's an Athlon64 3400+ on a Gigabyte motherboard - used mainly for >>>cross-compiling to Linux and mingw32, NFS file sharing, some X11 over the >>>network with my local Mac OS X machine as X server and using my own C/C++ >>>maths code (which must run as fast as possible). >>> >>>TIA >>> >>>Michael >>> >> >>The theoretical advantage of amd64 is that there are more registers and >>wider registers. This means that more effecient code can be generated >>by the compiler, especially math code. There is also the benefit of >>being able to address more than 4GB of RAM without requiring partial >>tricks like PAE. However, 64-bit addresses and pointers means that the >>cache gets consumed less efficiently. So, it's a tradeoff, and much of >>it probably relies on how well the compiler generates code. Of course, >>the large memory handling is a definite win, but if your application >>doesn't need that then the benefits are less clear. Still, the Athlon64 >>and Opteron CPUs are quite speedy. > > > What about a 64 bit kernel, and mixed mode (32bit and 64bit) > userland? Solaris does this, and it sounds efficient, from the comments > I've seen in this list. > > This way, only those programs which would benefit from 64bit > architecture would run in 64bit mode. > > > The bad part: Most (probably all) libraries would duplicated, and > the kernel and compiler should be modified to understand this "feature". > > If amd64 32bit executables were compatible with (maybe the same) > i386 executables, even better. Note that I am not talking about i386 > emulation. I am talking about native 32 bit executables in amd64 arch. > > Too hard to expect it in 6.0-RELEASE? Solaris indeed ships a 32-bit userland with 64-bit Solaris, and you are correct that it requires 2 versions of each library. There are also end-user toolchain issues to consider; you need a consistent way to get the expected results out of the compiler in this environment, and you also need to be able to make RTLD work in an expected manner. I think that some of this is being done in order to seamlessly support running i386 binaries, but again the real work is in making the toolchain make logical and correct choices. It's not something that is likely to happen for 6.0-RELEASE, but it's certainly a good project going forward for anyone who is motivated to help. Scott