🚀 go-pugleaf

In <Pine.SUN.3.91.950821100405.5161B-100000-100000@spad.eng.auburn.edu> "Jeffery D. Walker" <walkej2@eng.auburn.edu> writes:

>The MAJOR slowdown for a computer is NOT the cpu speed or the clock 
>speed, but the BUS SPEED!!!  If someone dissagres with me, try taking a 
>few computer engineering/electrical engineering courses and come back and 
>we will talk.

Maybe you should follow your own advice.  The speed of the external bus
is only one factor, amongst many others, affecting the speed of a
processor.  This is why doubling the size of the data bus (while keeping
all the others factors constant) doesn't double the speed of the cpu and
halving it doesn't half the cpu speed.  Is it that difficult to get a
clue before posting?

>this is why a 8088 is NOT considered a 16 bit machine, even though it 

This is why _you_ don't consider an 8088 to be a 16-bit cpu (it's by no
means a machine).  Your opinion is highly irrelevant.

>has 16bit registers.  a 8086 is a 16 bit machine, ONLY because it has a 
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>16 bit bus, no other reason; and it is this reason that makes it that 
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>much better. 
 ^^^^^^^^^^^
Bullshit.  Please quote some hard data, showing how much faster an 8086
is than an 8088 running at the same clock speed.

>This is also why a 100MHz-486DX-4 is slower (on average) 
>than even a 75MHz P5. the bus speed/width.(among other things)

If you stay within the L1 cache, the external bus width doesn't make
any difference.  And by your brain dead definition, the 386SX is a
16-bit chip and the Pentium is a 64-bit chip.  Do you _really_ believe
this crap?

The bitness of an architecture is not defined by the size of the external
data bus, period.  

It isn't defined by the speed of the data transfers, either.  A chip
with an 8-bit data bus running at 100 MHz (and no wait states) will
transfer data faster than a chip with a 64-bit data bus running at 10
MHz.  And in both cases, the bitness will be determined by the size of
the internal data paths, the registers and the ALU.

Dan
--
Dan Pop
CERN, CN Division
Email: Dan.Pop@mail.cern.ch 
Mail:  CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland

"Jeffery D. Walker" <walkej2@eng.auburn.edu> wrote:
>
>The MAJOR slowdown for a computer is NOT the cpu speed or the clock 
>speed, but the BUS SPEED!!!  If someone dissagres with me, try taking a 
>few computer engineering/electrical engineering courses and come back and 
>we will talk.
>

Technically, it's the buss throughput...  Datapath width and buss clock
speed.  Other than that, you are correct.  (Please give me as 128 bit buss.:)

-- 
Sphere.

Find a Linux/GNU Group for you: http://www.tiac.net/users/williams/lugnuts/
Buy Free UNIX!
Microsoft is prohibited from examining any packet containing data
originating on any machine which I am using. (Not that I can stop them.)

Jeffery D. Walker (walkej2@eng.auburn.edu) wrote:

: [Defines the bus]

: The MAJOR slowdown for a computer is NOT the cpu speed or the clock 
: speed, but the BUS SPEED!!!  If someone dissagres with me, try taking a 
: few computer engineering/electrical engineering courses and come back and 
: we will talk.

Hmm, a few people reading USENET belive it or not, have taken these
wonderful CE/EE classes, and have various pieces of nicely framed papers on
the wall to prove it.

: this is why a 8088 is NOT considered a 16 bit machine, even though it 
: has 16bit registers.  a 8086 is a 16 bit machine, ONLY because it has a 
: 16 bit bus, no other reason; and it is this reason that makes it that 
: much better.  This is also why a 100MHz-486DX-4 is slower (on average) 
: than even a 75MHz P5. the bus speed/width.(among other things)

This inane arguement as been going on for a while, but for all intents and
purposes, 8088 and 8086 are 16 bit CPUs, and the 386, 486, Pentium
Processor, and "P6" are 32 bit CPUs, this despite the fact that 386sx CPUs
have 16 bit external data bus, and The Pentium Processor has 64 bit
external data bus paths.  now, if you're a motherboard designer, then for
you, looking from the outside in, the 8088 looks like a 8 bit CPu, 8086
looks like 16 bit, and Pentium Processor looks like 64 bit.  It doesn't
change the fact that most reasonable CE/EEs around will take the internal
data bus width as the defining "bitness" of the processor. Just go ask any
one of your CE/EE profs, I'm sure that you'll be told that yes, 8088 really
is a 16 bit CPU.

: -------------------------------------------------
: Jeffery Walker                  Auburn University
: 04 CPE                       Computer Engineering
: walkej2@eng.auburn.edu
: "Real programmers don't document.  If it was hard
: to write, it should be hard to understand."
: -------------------------------------------------

: On 15 Aug 1995, Peter Payne wrote:

: > Dan Pop <Dan.Pop@mail.cern.ch> wrote:
: > 
: > > The size of the data bus is pretty irrelevant to the bitness of a processor.
: > > The sizes of the general purpose registers _and_ the ALU are the important
: > > factors.  This is what makes the 8088 a 16-bit cpu, the 386SX and the
: > > Pentium 32-bit cpu's and the 68000 so difficult to define :-)
: > 
: > What, in physical terms, is a bus and how would a 32-bit bus look
: > differently from a 16-bit one?
: > 
: > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
: > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
: > When I arrived at San Francisco airport, I surprised there are many
: > Americans around here. I thought American people had a large mind, warm
: > heart and were very kind. But American was fatter than Japanese.
: >                                 - Mieko-chan
: > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
: > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
: > 
: > 

Dan.Pop@mail.cern.ch (Dan Pop) wrote:
>In <Pine.SUN.3.91.950821100405.5161B-100000-100000@spad.eng.auburn.edu> >
>The bitness of an architecture is not defined by the size of the external
>data bus, period.  
>

Now I'm wondering if he used the word "external" anywhere.  I
won't go looking.

Will you agree that 1) memory is slower than cpu, and 2) most
programs don't fit in cache?  If this is true then the external
bus is generally the bottleneck.  I'm perfectly happy with a
definition of bitness which revolves about the bottleneck... In
fact that seems like a very good definition to me -- the bitness
of a machine is the path width of that portion of of the machine
which happens to be the usual bottleneck.  (Obviously not the
type of definition marketing managers would like...:)

-- 
Jim Williams.

Find a Linux/GNU User Group near you: 
http://www.tiac.net/users/williams/lugnuts/

In <41dejm$d1p@sundog.tiac.net> Jim Williams <williams@tiac.net> writes:

>Dan.Pop@mail.cern.ch (Dan Pop) wrote:
>>In <Pine.SUN.3.91.950821100405.5161B-100000-100000@spad.eng.auburn.edu> >
>>The bitness of an architecture is not defined by the size of the external
>>data bus, period.  
>>
>
>Now I'm wondering if he used the word "external" anywhere.  I
>won't go looking.

No need.  The internal data paths in the 8088 are 16-bit, so he was
obviously talking about the external data bus.
>
>Will you agree that 1) memory is slower than cpu, and 2) most
>programs don't fit in cache?  If this is true then the external
>bus is generally the bottleneck. 

Not necessarily.  You can write programs where the external bus is the
bottleneck, but this is not automatically true in the general case.
I/O bound and cpu bound programs are at least as common as memory bound
programs.

>I'm perfectly happy with a
>definition of bitness which revolves about the bottleneck... 

But you're obviously missing the fact that the bottleneck is application
specific (and some applications can be affected by more than one
bottleneck).  For someone generating fractals or doing data
compression, the cpu is the bottleneck.  And guess where is the
bottleneck for the "tar" and "cp" commands?  How about "ftp" and "rcp"? :-)

>In
>fact that seems like a very good definition to me -- the bitness
>of a machine is the path width of that portion of of the machine
>which happens to be the usual bottleneck.  

Too bad your definition is rendered useless by the fact that there is no
usual bottleneck.  When memory started to become a real bottleneck, the
chip manufacturers introduced the built-in cache.

Dan
--
Dan Pop
CERN, CN Division
Email: Dan.Pop@mail.cern.ch 
Mail:  CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland

Dan.Pop@mail.cern.ch (Dan Pop) wrote:
>In <41dejm$d1p@sundog.tiac.net> Jim Williams <williams@tiac.net> writes:
>>Will you agree that 1) memory is slower than cpu, and 2) most
>>programs don't fit in cache?  If this is true then the external
>>bus is generally the bottleneck. 
>
>Not necessarily.  You can write programs where the external bus is the
>bottleneck, but this is not automatically true in the general case.
>I/O bound and cpu bound programs are at least as common as memory bound
>programs.

Someone else made similar points (less politely), but that message
doesn't seem to have made it to my news server...

I'm not so sure that I/O and cpu are directly related, but I must admit
that the newer methods of CPU load balancing probably make my statements
a bit off-base.  Either I should go back and study current chip
designs more carefully or bitness should be dropped as an indicator
of chip throughput.  I vote we do away with bitness. :)

>
>>I'm perfectly happy with a
>>definition of bitness which revolves about the bottleneck... 
>
>But you're obviously missing the fact that the bottleneck is application
>specific (and some applications can be affected by more than one
>bottleneck).  For someone generating fractals or doing data
>compression, the cpu is the bottleneck.  And guess where is the
>bottleneck for the "tar" and "cp" commands?  How about "ftp" and "rcp"? :-)
>

I didn't really miss the application specific nature of bottlenecks,
but I do seem off on the relationship between bitness as a measure
of throughput and the possible location of bottlenecks.  It was easier
in the old days when memory, I/O, and just about everything else was
out on the bus.

With the newer placements of a little here a little there I really
wonder if bitness is a meaningfull concept.  If you can't use it
to roughly gauge throughput then what good is it?

>>In
>>fact that seems like a very good definition to me -- the bitness
>>of a machine is the path width of that portion of of the machine
>>which happens to be the usual bottleneck.  
>
>Too bad your definition is rendered useless by the fact that there is no
>usual bottleneck.  When memory started to become a real bottleneck, the
>chip manufacturers introduced the built-in cache.
>

There must be some normal distibution of bottleneckness (nice word).
Where are the current bottlenecks, and what loads cause them?  If
I can't use bitness as a measure then I need to find a replacement.

-- 
Sphere.

Find a Linux/GNU Group for you: http://www.tiac.net/users/williams/lugnuts/
Buy Free UNIX!
Microsoft is prohibited from examining any packet containing data
originating on any machine which I am using. (Not that I can stop them.)

Dan Pop (Dan.Pop@mail.cern.ch) spewed forth the following profound insight:
==> In <41dejm$d1p@sundog.tiac.net> Jim Williams <williams@tiac.net> writes:

==> >Dan.Pop@mail.cern.ch (Dan Pop) wrote:
==> >>In <Pine.SUN.3.91.950821100405.5161B-100000-100000@spad.eng.auburn.edu> >

==> >>The bitness of an architecture is not defined by the size of the external
==> >>data bus, period.                                                ^^^^^^^^
==> >>                                                                 ^^^^^^^^
==>                                                                    ^^^^^^^^
==>                                                                    ^^^^^^^^
==>                                                                    ^^^^^^^^

==> >Now I'm wondering if he used the word "external" anywhere.  I
==> >won't go looking.

==> No need.  The internal data paths in the 8088 are 16-bit, so he was
==> obviously talking about the external data bus.

    I was going to follow up to this with a big rant about how you two 
could up the average IQ of comp.sys.powerpc by at least 37 points simply 
by posting to more relevant groups (like bozo.argue.*.advocacy), but I 
have to go talk to my advisor, and get a haircut.  I will instead just 
let you look at the quoted text above and reflect.  

    Now, I know this could just be a horrific troll, but I have been 
reading your posts for several months now, and can safely discount that 
as a possibility.  HTH!

                                                            -Caj
--
             88     
  ,ad8888ba, "" <=-- That's right - the '@' character is actually MY NAME,   
 d8P'    `"':88 <=-- reduced 10.7 times for transmission purposes.  Forget
d8:         ;88 <=-- some stupid name like "octothorpe" or "virgule":  the
88:   ,adPYa888 <=-- '@' is hereby officially called the CAJ!!1!  All that
88:   88    `88 <=-- time you spent programming in FORTH you were actually
Y8:   88,   ,88 <=-- aiding, unwittingly, the propagation of my *almighty*
 Y8a. `Ybaa8P88 <=-- *wisdom*!  KIBO may have a newsgroup and a stupid lil
o `"Y8888YP"d8P <=-- dog, but I RESIDE IN ASCII!!!!!  I AM IMMORTAL!!!11!!
Yb,       _,8P'       
`YY88888888P"'     z911588@mp.cs.niu.edu -- My opinions do not represent.

In article <danpop.809177909@rscernix> Dan Pop, Dan.Pop@mail.cern.ch
writes:
>>programs don't fit in cache?  If this is true then the external
>>bus is generally the bottleneck. 
>
>Not necessarily.  You can write programs where the external bus is the
>bottleneck, but this is not automatically true in the general case.
>I/O bound and cpu bound programs are at least as common as memory bound
>programs.
>

Basically what you're implying is that real-life programs could often fit
in
the internal cache?  Come on!  What about the fact that the OS is
constantly
switching processes and servicing interrupts?  What about the fact that
most
programs consist of *some* sections of high temporal locality, but
regularly
branch outside?

Yes, not *every* piece of code is automatically limited by the external
bus
bottleneck, but that is generally the case.  It only gets worse at higher
clock speeds.

For instance, the Alpha processor uses a 128-bit data bus on the 21064 and
21164 implementations.  It would not get near its current performance
levels
without that.  That gives a theoretical bandwidth limit of 1.5 GB per
second
at 300MHz.(using the maximum 100MHz data bus)  At that high clockspeed,
the
processor would be severely slowed down on cache misses if the data bus
were
64 bits.

Steve Bakke
Computer Engineering
University of Cincinnati

In article <danpop.809177909@rscernix> Dan Pop, Dan.Pop@mail.cern.ch
writes:
>bottleneck).  For someone generating fractals or doing data
>compression, the cpu is the bottleneck.  And guess where is the
>bottleneck for the "tar" and "cp" commands?  How about "ftp" and "rcp"? :-)
>

The code would probably remain in the cache for compression.  But what
about
data?  For most compression, the file would have to take up several
blocks in
the cache causing cache misses.  The time for those cache fills is
probably pretty
large compared to the compression execution time which significantly
lengthens the
amount of time needed to complete the operation.

Steve Bakke
Computer Engineering
University of Cincinnati