cvsup on amd64 just broke today
David O'Brien
obrien at freebsd.org
Sun Aug 29 16:36:31 PDT 2004
On Sun, Aug 29, 2004 at 04:07:44PM -0700, Sean McNeil wrote:
> Finally catching up on your email? ;)
Yeah. :-/
> On Sun, 2004-08-29 at 15:53, David O'Brien wrote:
> > Why is it odd?!?
> > The ability to run legacy 32-bit x86 binaries under a 64-bit OS at
> > full-speed is one of the huge capabilities AMD brought with this
> > architecture. Unless a binary does 64-bit math or addresses >4GB of
> > memory why does something need to be 64-bit???
>
> This is a little misleading. You are throwing out the fact that the
> amd64 has additional features in 64-bit mode that can significantly
> increase performance. Such as extra registers.
I'm not throwing out the fact about the extra registers. In my day-job I
track AMD performance. Trust me, for a network-based program such as
CVSup isn't going to reap a noticeable benefit from them. What slows down
CVSup is network BW and latency, same for the disk BW and latency. CVSup
isn't doing Seti at Home calculations.
> > The fact that all Open Source OS's have a 64-bit userland on all their
> > 64-bit platforms that grew up from 32-bit CPU's shows how unsophisticated
> > our build framework is. "64-bit" Solaris today is really a 64-bit kernel
> > and mostly 32-bit userland.
>
> Except Solaris has identical architectures that were extended to
> 64-bit.
Actually Sparc isn't 100% identical -- performance enhancements were made
in 64-bit mode. They just aren't as many and to the extent as done in
AMD64.
> amd64 is a slightly different story.
Solaris for AMD64 will also have a 32-bit userland, and its compiler will
default to producing 32-bit binaries. For things like 'vi' and 'ls'
64-bit + extra registers simply doesn't matter.
--
-- David (obrien at FreeBSD.org)
More information about the freebsd-amd64
mailing list