🚀 go-pugleaf

In article <458mrk$enl@inferno.mpx.com.au>, msmith@jolt.mpx.com.au (Michael Smith) writes:
|> It sounds as though everyone is agreeing with each other.  We can't have 
|> that in this news group.  Allow me to supply an opposing point of view.
|> 
|> There are two reasons for increasing your bus size.
|> 	1.  To address more memory
|> 	2.  To increase throughput (bandwidth).

Reason 2 is invalid. See below.

|> Very few people (who I know anyway) buy 64 bit machines to address more 
|> than 4GB of memory.  They do it to get faster throughput.  The extra 
|> address space is simply a side-effect.  While increasing your bus from 32 
|> to 64 bits may increase your address space by an enormous amount, it only 
|> increases the throughput by a factor of 2.  I can easily imagine users 
|> (in the next few years) wanting 128 bit graphics cards, disk controllers 
|> and network interface cards and thus wanting a 128 bit bus.

Bus width and addressing are orthogonal issues.  They aren't even at the
same "level" of processor design.  By this I mean that address width is
an architectural feature:  once it's in there, you can't change it
without altering the ISA.  Bus width is strictly an implementation
decision.  Within a given architecture (let's use x86 for x >= 3 as an
example) it is possible to have implementations for which the system bus
width is less than the architected address width (the 80386SX),
implementations in which they are equal (80386DX, all common 80486
variants), and implementations in which the system bus width is greater
than the architected address width (non-Overdrive Pentia, P6).  I am
careful to say "architected address width" because the actual number of
address lines may be less than this value.

The bottom line is that address size has no bearing on raw bus throughput.
It does impact *usable* bus throughput inasmuch as you may waste bandwidth
while dealing with extra-large pointers... :-)

|> There!  That should start an argument.

Not really.

----------------------------------------------------------------------------
Patrick Chase		Not speaking for Hewlett-Packard...
H-P San Diego