🚀 go-pugleaf

In article <45kb7c$sql@news.xs4all.nl>, Gertjan Klein <gklein@xs4all.nl> wrote:
>albaugh@agames.com (Mike Albaugh) wrote:
>> Gertjan Klein (gklein@xs4all.nl) wrote:
>
>> 	Reality check time. The _best_ a 64-bit data bus can do is
>> twice the throughput of an otherwise identical 32-bit data bus.
>> This is one of those "Speed of light" issues (guaranteed not to
>> exceed). Unless you do only memcpy() of your entire data space,
>> you will not actually reach this figure.
>
>  You won't get an arguement from me; I completely agree. The point I
>was trying to make was that increasing the _address_ bus doesn't get
>you any improvement in throughput at all, as Michael Smith originally
>claimed. 
>

It's worse than that.  Increasing the hardware-supported address size
*reduces* throughput.  Pointer data end up taking up more space, despite
the fact that they contain very little information.  Taking up more
space translates into a bandwidth *cost*, because you're communicating
a whole lot of bits that are incredibly redundant.

This is why I think that increasing the address bus size unnecessarily
is crazy.  64 bits is okay, since we'll have main memories too big
for 32 bit buses---but beyond that is lunacy.  (We can even make 32
bit buses work well for very large main memories, if we're clever.)

Why put something that almost by definition goes unused almost all the
time right smack in the critical path (and data paths) of your hardware?
Wouldn't you rather use those paths for communicating useful information?
Pointer swizzling and (other) forms of compression let you optimize
the use of your data paths, rather than throwing expensive hardware
at the problem.

-- 
| Paul R. Wilson, Comp. Sci. Dept., U of Texas @ Austin (wilson@cs.utexas.edu)
| Papers on memory allocators, garbage collection, memory hierarchies,
| persistence and  Scheme interpreters and compilers available via ftp from 
| ftp.cs.utexas.edu, in pub/garbage (or http://www.cs.utexas.edu/users/wilson/)