Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 13 May 2005 13:50:39 -0600
From:      Scott Long <scottl@samsco.org>
To:        =?ISO-8859-1?Q?Jo=E3o_Carlos_Mendes_Lu=EDs?= <jonny@jonny.eng.br>
Cc:        "freebsd-amd64@freebsd.org" <freebsd-amd64@freebsd.org>
Subject:   Re: Actual benefits of amd64 over i386
Message-ID:  <4285050F.7000202@samsco.org>
In-Reply-To: <4284FD37.2070009@jonny.eng.br>
References:  <BEA97082.3CD55%michael.hopkins@hopkins-research.com> <42842F46.9040608@samsco.org> <4284FD37.2070009@jonny.eng.br>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4285050F.7000202>