PowerPC 620...any opinions?
Tom Petersen
Specifically, I am curious what conceptions/misconceptions people hold
about the PowerPC 620's 64-bitness, and how this plays with the rest
of the family.
Let me know what you think.
TAP
--
Thomas A. Petersen (I) Somerset 620
t...@ibmoto.com
Mark Hendriks
> What is the general perception of compatability across the PowerPC family.
> Specifically, I am curious what conceptions/misconceptions people hold
> about the PowerPC 620's 64-bitness, and how this plays with the rest
> of the family.
Here's the deal with with the PPC line: the 604 will replace the 601, but after
that, the other members serve different functions. That means that the 602,
603e, 604, and 620 will all be on the market at the same time, but will be
targeted at different segments of the market (not just high/low end).
602 - low cost, low power (embedded systems?)
603e - laptops
604 - general systems (personal computers, workstations)
620 - server systems
These chips are not just direct decendants of each other, but are designed for
different purposes. For example, the 620 is optimized for transaction
processing, but will not offer significant advantages over the 604 to the
general user. This is designed to give PPC a broader range of appeal without
making sacrifices.
#------------------------------ Mark H. Hendriks ------------------------------#
My _Theory_of_Everything_:
1 + 1 = 2; The rest is left as an exercise for the reader.
My Real Name: mhhe...@descartes.uwaterloo.ca
Life is a test of how far you can go beyond 1 + 1.
Tom Petersen
: From: t...@wang.ibmoto.com (Tom Petersen)
: > What is the general perception of compatability across the PowerPC family.
: > Specifically, I am curious what conceptions/misconceptions people hold
: > about the PowerPC 620's 64-bitness, and how this plays with the rest
: > of the family.
: Here's the deal with with the PPC line: the 604 will replace the 601, but after
: that, the other members serve different functions. That means that the 602,
: 603e, 604, and 620 will all be on the market at the same time, but will be
: targeted at different segments of the market (not just high/low end).
: 602 - low cost, low power (embedded systems?)
: 603e - laptops
: 604 - general systems (personal computers, workstations)
: 620 - server systems
: These chips are not just direct decendants of each other, but are designed for
: different purposes. For example, the 620 is optimized for transaction
: processing, but will not offer significant advantages over the 604 to the
: general user. This is designed to give PPC a broader range of appeal without
: making sacrifices.
Thanks for your input Mark, but I am really more interested in how
people view the 620 technically. Is 64-bitness a good thing? If
anyone likes the 620's 64-bit features, tell me what and why. What
are the customer expectations?
Thanks,
TAP
--
Thomas A. Petersen (I) Somerset 620 DCMMU
t...@ibmoto.com (512) 795-7090
Noah Daniels
mhhe...@zeno23.math.UWaterloo.ca (Mark Hendriks) wrote:
> 602 - low cost, low power (embedded systems?)
> 603e - laptops
> 604 - general systems (personal computers, workstations)
> 620 - server systems
>
> These chips are not just direct decendants of each other, but are designed for
> different purposes. For example, the 620 is optimized for transaction
> processing, but will not offer significant advantages over the 604 to the
> general user. This is designed to give PPC a broader range of appeal without
> making sacrifices.
>
>
So the fact that the 8400's chip will be on a daughterboard means you'll
be able to swap it for a faster 604? Or whatever descends from a 604?
What's the deal?
--
-=Noah M. Daniels=-
{ndan...@cc.swarthmore.edu}
"Gott Wuerfelt Nicht" - Albert Einstein
(God does not play dice)
Steven E. Bakke
t...@nunez.ibmoto.com writes:
>Thanks for your input Mark, but I am really more interested in how
>people view the 620 technically. Is 64-bitness a good thing? If
>anyone likes the 620's 64-bit features, tell me what and why. What
>are the customer expectations?
>
>Thanks,
>
>TAP
>
You asked for a technical opinion - here it is. First of all, the average
home user does not currently need what '64 bitness' offers. That aside, I
will talk about what it does offer.
Probably the first thing the 620 will offer, is that all of its registers
are 64 bits in length allowing integer calculations of much higher
precision
natively.(it is possible on 32 bit machines only in software) The other
advantage of a 64-bit chip is its 64-bit addressing space. This is where
the home market has some years to go before it is needed. Currently,
32-bit
machines allow a theoretical 4 GB of addressable memory space. For
business
and high-end work, this space is actually running out. Sounds hard to
believe, but I have witnessed a machine crash hard when it ran out of
virtual
addressing space!
I can understand the 620 not necessarily being used in desktops. It
is not necessary for most of the mass market. Meanwhile, Apple and other
companies can plan ahead to take advantage of the new capabilities.
-Steve Bakke
University of Cincinnati
Michael Shandony
Tom Petersen <t...@wang.ibmoto.com> wrote:
>What is the general perception of compatability across the PowerPC family.
>
>Specifically, I am curious what conceptions/misconceptions people hold
>about the PowerPC 620's 64-bitness, and how this plays with the rest
>of the family.
What is the compatibility of compiled code between say the PPC 601/603/604
and the PPC 620? I assume that code compiled for either the 601/603/604
will be able to run unmodified on a 620, but the opposite is not true.
Correct?
=====================================================================
Mike Shandony | Telephone: (214) 684-7303
Bell-Northern Research, Inc. | BNR/NT Internal: (ESN) 444-7303
2201 Lakeside Blvd. MS D0307 | Fax: (214) 684-3748
Richardson, TX 75082-4399 | Internet: vanh...@bnr.ca
=====================================================================
Patrick Gainer
Mark Hendriks <mhhe...@zeno23.math.UWaterloo.ca> wrote:
>For example, the 620 is optimized for transaction
>processing, but will not offer significant advantages over the 604 to the
>general user. This is designed to give PPC a broader range of appeal without
>making sacrifices.
I keep hearing this chanted like a mantra but I haven't seen any posts
where the posters actually explain this phrase "optimized for transaction
processing". What optimizations do you think have been made for tp?
Pat
Joachim Isaksson
>people view the 620 technically. Is 64-bitness a good thing? If
>anyone likes the 620's 64-bit features, tell me what and why. What
>are the customer expectations?
>Thanks,
>TAP
I'll not be able to afford one for a while, but I'd really love a 64 bit
addressing range. Being able to memory map whole file systems is something
that would appeal to me greatly, since I don't at all appreciate UNIX file
I/O ;) I don't think the 64 bit integer range would be of much use to me
though... I'd much rather have 128 bit floats... :)
/me
Steve Peltz
Steven E. Bakke <ba...@bearcat.iii.net> wrote:
>Probably the first thing the 620 will offer, is that all of its registers
>are 64 bits in length allowing integer calculations of much higher
>precision natively.
Very few integer calculations need more then 32 bits, but it is definitely
convenient to not even worry about extraordinary situations. For example,
in 32 bits you only get about 136 years worth of seconds; in 64 bits, you
get about 584 BILLION years worth of seconds (or you can make it be 584
years worth of nanoseconds).
>advantage of a 64-bit chip is its 64-bit addressing space. This is
>where the home market has some years to go before it is needed.
>Currently, 32-bit machines allow a theoretical 4 GB of addressable
>memory space. For business and high-end work, this space is actually
>running out. Sounds hard to believe, but I have witnessed a machine
>crash hard when it ran out of virtual addressing space!
Very few things need 4GB of address space. One of the few is high-end
photo quality image manipulation (85 4096 by 4096 24-bit color images
are about 4 GB). Doing database manipulation keeping everything in
memory instead of using a file system would be another (for a large
database). Most people consider 4GB of DISK space to be a lot, though.
It is convenient to be able to give yourself a 4GB stack area and not
even consider for the merest moment of time that it might possibly conflict
with anything else (since you have 4 billion such 4GB data areas available).
Are you sure the machine that crashed didn't run out of swap space instead
of virtual address space? Crashing isn't the normal way of handling such
a situation anyway.
The obvious advantage that 64-bit machines have is memory transfer rates,
which is probably why people think of it as being a feature designed for
servers. Of course, for a lot of that, simply having a 128-bit wide DMA
controller (and the memory to match) would do much the same thing.
I'm interested in the 620 for use in emulating a Cyber (60-bit word); it
will have to be pretty fast to do as well as an Alpha, though (floating
point speed is almost entirely irrelevant for such an emulator - the only
use I make of floating point is to do a normalize. The Cyber floating point
format and behavior just doesn't map well onto IEEE).
--
Steve Peltz
tri...@uiuc.edu
Lawson English
: In article <D6oqp...@undergrad.math.uwaterloo.ca>,
: Pat
Isn't the data bus 128-bits?
--
-------------------------------------------------------------------------------
Lawson English __ __ ____ ___ ___ ____
eng...@primenet.com /__)/__) / / / / /_ /\ / /_ /
/ / \ / / / / /__ / \/ /___ /
-------------------------------------------------------------------------------
Mark Hendriks
> Well... Transaction Processing is a biggie for me. How much faster
> would a 620 based server (Something like an R30 but with 150Mhz 620's
> in it (Lets see... 601=R30, 604=R40? 620=R50?)) be than an R24? (IBM
> figures for tpm on the R24 are 1470 or thereabouts (4 processor
> R30=1410)).
> The ability to handle 64-bit stuff would be great if IBM OS's can be
> enabled for it. For example if it makes AIX support files > 2GB faster,
> then I'm all for it.... Haveing a wider path to memory as well... WIll
> that speed up tpm's?
For this kind of techie info, you should check out IBM's Web page. As 620 based
systems are not available yet, it might not be on the Products page, but they
might have something on the technology page.
http://www.ibm.com/Technology/
If not, they got things set up to make it relatively easy to poke around.
Nick Maclaren
Patrick Gainer <gai...@engr.sgi.com> wrote:
>In article <D6oqp...@undergrad.math.uwaterloo.ca>,
>Mark Hendriks <mhhe...@zeno23.math.UWaterloo.ca> wrote:
>>For example, the 620 is optimized for transaction
>>processing, but will not offer significant advantages over the 604 to the
>>general user. This is designed to give PPC a broader range of appeal without
>>making sacrifices.
>
>I keep hearing this chanted like a mantra but I haven't seen any posts
>where the posters actually explain this phrase "optimized for transaction
>processing". What optimizations do you think have been made for tp?
The fundamental differences between the 620 and 604 are in the areas
of memory management, multiple-processor support, I/O support etc.
Saying that it is optimised for TP is rather misleading - a better
way to think of it is that it is a chip intended for use in 'servers'
rather than 'workstations'. And I don't mean CPU servers ....
Nick Maclaren,
University of Cambridge Computer Laboratory,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email: nm...@cam.ac.uk
Tel.: +44 1223 334761 Fax: +44 1223 334679
Evan Torrie
>In article <D6oqp...@undergrad.math.uwaterloo.ca>,
>Mark Hendriks <mhhe...@zeno23.math.UWaterloo.ca> wrote:
>>For example, the 620 is optimized for transaction
>>processing
>I keep hearing this chanted like a mantra but I haven't seen any posts
>where the posters actually explain this phrase "optimized for transaction
>processing". What optimizations do you think have been made for tp?
Transaction Processing => poor locality of reference (unlike SPEC)
=> require fast, wide memory system
Witness PowerPC 620: 128 bit-wide memory bus
separate 2nd level cache interface
--
------------------------------------------------------------------------------
<A HREF="http://liber.stanford.edu/~torrie/">Evan Torrie</A>.
Stanford University, Class of 199? tor...@cs.stanford.edu (finger for PGP)
"The difference between our [Apple's] software strategy and Microsoft's
software strategy is about two weeks." - Dave Nagel, Apple VP.
Hamish Marson
> Mark Hendriks (mhhe...@zeno23.math.UWaterloo.ca) wrote:
> : From: t...@wang.ibmoto.com (Tom Petersen)
> Thanks for your input Mark, but I am really more interested in how
> people view the 620 technically. Is 64-bitness a good thing? If
> anyone likes the 620's 64-bit features, tell me what and why. What
> are the customer expectations?
Well... Transaction Processing is a biggie for me. How much faster
would a 620 based server (Something like an R30 but with 150Mhz 620's
in it (Lets see... 601=R30, 604=R40? 620=R50?)) be than an R24? (IBM
figures for tpm on the R24 are 1470 or thereabouts (4 processor
R30=1410)).
The ability to handle 64-bit stuff would be great if IBM OS's can be
enabled for it. For example if it makes AIX support files > 2GB faster,
then I'm all for it.... Haveing a wider path to memory as well... WIll
that speed up tpm's?
> Thanks,
--
======================================================================
| Hamish Marson |
| Systems Programmer | |
| Computer Services | INTERNET h.ma...@waikato.ac.nz |
| University of Waikato | PHONE +64 7 8562889 xt 8181 |
| New Zealand | FAX +64 7 8384066 |
===========Disclaimer :- Remember. You heard it here first.===========
Patrick Gainer
>In article <3mbm67$7...@fido.asd.sgi.com>,
>Patrick Gainer <gai...@engr.sgi.com> wrote:
>>where the posters actually explain this phrase "optimized for transaction
>>processing". What optimizations do you think have been made for tp?
>
>of memory management, multiple-processor support, I/O support etc.
Yes, and without intending to be sarcastic, you haven't answered the
question. What are the "fundamental differences" in I/O support,
SMP support, and memory mgmt between the 604 and 620?
Pat
Patrick Gainer
Mark Hendriks <mhhe...@zeno15.math.UWaterloo.ca> wrote:
>From: ham...@waikato.ac.nz (Hamish Marson)
>> Well... Transaction Processing is a biggie for me. How much faster
>> would a 620 based server (Something like an R30 but with 150Mhz 620's
>> in it (Lets see... 601=R30, 604=R40? 620=R50?)) be than an R24? (IBM
>> figures for tpm on the R24 are 1470 or thereabouts (4 processor
>> R30=1410)).
>
>> The ability to handle 64-bit stuff would be great if IBM OS's can be
>> enabled for it. For example if it makes AIX support files > 2GB faster,
>> then I'm all for it.... Haveing a wider path to memory as well... WIll
>> that speed up tpm's?
You don't need 64 bit support to enable transaction processing on data
sets larger than 2 gig. You just need an RDBMS. For example, DB2/6000,
which you have quoted tpmC figures for, has no real data size
limitation.
What will go the farthest in speeding up the transaction rate is high
memory bandwidth and low memory latency.
Pat
Nick Maclaren
Patrick Gainer <gai...@engr.sgi.com> wrote:
>In a recent append, Nick Maclaren <nm...@cus.cam.ac.uk> wrote:
>>In article <3mbm67$7...@fido.asd.sgi.com>,
>>Patrick Gainer <gai...@engr.sgi.com> wrote:
>>>I keep hearing this chanted like a mantra but I haven't seen any posts
>>>where the posters actually explain this phrase "optimized for transaction
>>>processing". What optimizations do you think have been made for tp?
>>
>>The fundamental differences between the 620 and 604 are in the areas
>>of memory management, multiple-processor support, I/O support etc.
>
>Yes, and without intending to be sarcastic, you haven't answered the
>question. What are the "fundamental differences" in I/O support,
>SMP support, and memory mgmt between the 604 and 620?
Ah, you have just dropped a level into more technical areas. I.e. I
don't know the exact differences, and the people that I have spoken
to didn't either. There is the obvious fact that its address bus is
64 bits, not 32, but there are supposed to be many other aspects. For
example:
More cached TLBs & contexts - i.e. it can run more processes,
without losing efficiency.
Ability to do more memory, cache and I/O transfers in parallel.
I was told both of these, and then the information descended into
flannelling. To find out EXACTLY what is different, you would need
to get at the hardware manuals. The point that I was making is that
the 620 is more like the CPU of a minicomputer than that of a modern
workstation. I agree that, if anyone knows the PRECISE differences,
posting them would be appreciated. I don't know them.
Jeff Medcalf (214) 280-5970 IBM SDO
> Here's the deal with with the PPC line: the 604 will replace the 601, but after
> that, the other members serve different functions. That means that the 602,
> 603e, 604, and 620 will all be on the market at the same time, but will be
> targeted at different segments of the market (not just high/low end).
>
Actually, embedded systems use the 4xx and 5xx lines.
The 602 is for game machines.
> 603e - laptops
And low-end desktops.
> 604 - general systems (personal computers, workstations)
> 620 - server systems
--
+-------------+-------------------------------+--------------------------+
|Jeff Medcalf | med...@interlock.dfw.ibm.com | |
|IBM SDO | JKMe...@aol.com | I am Pentium of Borg. |
+-------------+-------------------------------+ Division is futile. |
|I not only don't speak for IBM, | You will be approximated.|
|I don't even *know* who speaks for IBM! | |
+---------------------------------------------+--------------------------+
Hamish Marson
> In article <D6tyM...@undergrad.math.uwaterloo.ca>,
> Mark Hendriks <mhhe...@zeno15.math.UWaterloo.ca> wrote:
> >From: ham...@waikato.ac.nz (Hamish Marson)
> >> Well... Transaction Processing is a biggie for me. How much faster
> >> would a 620 based server (Something like an R30 but with 150Mhz 620's
> >> in it (Lets see... 601=R30, 604=R40? 620=R50?)) be than an R24? (IBM
> >> figures for tpm on the R24 are 1470 or thereabouts (4 processor
> >> R30=1410)).
> >
> >> The ability to handle 64-bit stuff would be great if IBM OS's can be
> >> enabled for it. For example if it makes AIX support files > 2GB faster,
> >> then I'm all for it.... Haveing a wider path to memory as well... WIll
> >> that speed up tpm's?
> You don't need 64 bit support to enable transaction processing on data
> sets larger than 2 gig. You just need an RDBMS. For example, DB2/6000,
> which you have quoted tpmC figures for, has no real data size
> limitation.
No you don't. However it makes it a lot easier to handle large amounts
of data if your CPU is able to handle the large numbers involved natively,
rather than in emulation. (FOr instance, a 64bit key comparison. Any key
comparison for keys > 32 bits can be faster on a 64 bit machine than
on a 32 bit machine, simply because you only need 1/2 the number of
comparisons). Thats where transaction processing can really fly.
Oh yeah. I don't know if the tpm;c I quoted above were for DB/2, the
advertising doesn't say. But I believe they are done with the same
data and RDBMS, so go a long way toward pointing out the speed defference
between members of the RS6k family.
> What will go the farthest in speeding up the transaction rate is high
> memory bandwidth and low memory latency.
True... Which the 128 bit memory interface on the 620 does wonders for.
Of couse so does an L2 cache (Whitness the difference between the 990
and the R24 (Both RS6000's), the 990 has 256bit path to memory, and
the R24 only a 128 bit path, also the 990 has 256kb data cache (L1) while
the R24 only has 128kb, yet the R24 outperforms the 990 in tpm's by about
50%).
> Pat
Patrick Gainer
In a recent append, Nick Maclaren <nm...@cus.cam.ac.uk> wrote:
>In article <3me840$1...@fido.asd.sgi.com>,
>Patrick Gainer <gai...@engr.sgi.com> wrote:
>>In a recent append, Nick Maclaren <nm...@cus.cam.ac.uk> wrote:
>>>
>>>The fundamental differences between the 620 and 604 are in the areas
>>>of memory management, multiple-processor support, I/O support etc.
>>
>>Yes, and without intending to be sarcastic, you haven't answered the
>>question. What are the "fundamental differences" in I/O support,
>>SMP support, and memory mgmt between the 604 and 620?
>
>Ah, you have just dropped a level into more technical areas. I.e. I
>don't know the exact differences, and the people that I have spoken
>to didn't either. There is the obvious fact that its address bus is
>64 bits, not 32, but there are supposed to be many other aspects. For
Well, from the little I could could find at the Motorola home page, I
was able to deduce some differences but was confused by others.
Here are some of the differences I noticed which might help TP
processing specifically.
Both 604 and 620 have 128 entry TLBs but the 620 also has
a "64 entry, associative, effective-to-real translation cache". I
wonder how this differs from a TLB? What is this caching that the TLB
doesn't cache?
The 604 has 16K, 4-way set associative I and D L1 caches while the 620 has
32K, 8 way set associative L1 I and D caches. High associativity and
a 32K I cache would benefit TP loads.
The 604 has a 64 bit data bus while the 620 has a 128 bit data bus.
This implies higher bandwidth between CPU and L2 and L2 and memory.
The 620 has "two MMUs for instructions and data".
Both chips include on-chip logic for bus snooping (SMP).
That's all I could find. Maybe there are other differences and somebody
in the know could tell us?
However, from the Motorola home page, it doesn't look like there are
fundamental differences in SMP support. It does look like there is more
inherent parallelism in the MMU area but with the short descriptions
provided who can tell? There is also no indication of "fundamentally
different I/O support.
Pat
Hamish Marson
> In article <3mfepf$1i...@thebes.waikato.ac.nz>,
> Hamish Marson <ham...@waikato.ac.nz> wrote:
> >Of couse so does an L2 cache (Whitness the difference between the 990
> >and the R24 (Both RS6000's), the 990 has 256bit path to memory, and
> >the R24 only a 128 bit path, also the 990 has 256kb data cache (L1) while
> >the R24 only has 128kb, yet the R24 outperforms the 990 in tpm's by about
> >50%).
> Something to note is one cannot compare the tpmC rates directly
> between the 990 and the R24 as different database systems were used.
> The R24 runs and the SMP runs were done with DB2/6000 v2.1. I don't
> know what was used for any 990 runs but it wasn't DB2/6000 v2.1.
> Therefore, it is not clear how much faster in tp the R24 is over the
> 990 when using the tpmC metric.
Are the figures quoted in the ibm WWW page tpmC figures? Or some other
benchmark? I saw some from an IBM tech that showed figures for differnt
database managers and different machines (Table sort of. You know...
The R24 came in about 50% faster than the 990 (In the advertising glossy
I have its almost 2x as fast (I think the glossy has tpmC?)).
Tom Petersen
: Both 604 and 620 have 128 entry TLBs but the 620 also has
: a "64 entry, associative, effective-to-real translation cache". I
: wonder how this differs from a TLB? What is this caching that the TLB
: doesn't cache?
PowerPC segmented translation is defined using a 2-stage mechanism
(EA->VA then VA->RA). The SLB/Segreg array caches EA->VA
translations. Logically, the VA is then used to access a TLB which
caches the VA->RA mappings (actually this TLB access ocurrs in
parallel with the SLB access; An external comparison validates VA
correlation). When you finish the lookup process you get an
association EA->RA. This is what we cache in the "64 entry,
fully-associative, effective-to-real translation cache" or ERAT.
--
Gordon
instructions per cycle, they have the same number and types of
execution units. So from a purely instruction execution view
they are equal.
Where they differ are in the 64 bit mode, the caches are implemented
differently, the L2 controller and the bus is the 6xx bus not the
60x bus (tagged vs. non-tagged). The 620 handles branches differently
than the 604 (604 resolves sooner by using BBID), the 620 has more
writeback ports on it's register files so there is no hazards from
writeback, the 620 hard wires it's dispatch where the 604 doesn't.
I would believe in ispec/mhz they are about identical. IMHO if you
don't need 64 bits the 604 will be cheaper and perform as well.
Bill Moyer
>announced? They are the ones based on the new 21164 chip. Oracle
>also announced a version of their database software which is written to
>fully take advantage of the '64-bitness' of the Alpha. The top-end
>machine has 12 CPU's running at 300MHz each and something like a gigabyte
>or more of main memory.
:-) It's good to hear!
>It has a memory bandwidth of 1200MB/sec. For one million
>dollars, it blows away IBM's $20 million mainframe.
Careful now.. Memory bandwidth is not what mainframes are built for.
Mainframes are built to support tremendous amounts of peripheral IO,
usually without loading the CPU. The 80MHz 486 on my desk could blow
away the old VAX 780 (a minicomputer) in number-crunching and memory
bandwidth, but the PC motherboard couldn't hold a candle to the old
VAX's peripheral management capabilities.
>I think of computing power like Field of Dreams - "If you build it, they
>will come..." Similarly, if you build a much faster/more capable
>computer,
>somebody will find a way to max it out.
>
>We will never have enough speed and power. Someone always finds a reason
>to need more.
Yeah.. There's an old, old maxim in the computer industry that goes
something like "Program requirements will grow to consume all available
resources." ie, if the amount of RAM on the average PC doubles, then
the amount of RAM needed to run the average PC app also doubles. Like-
wise with CPU power, disk space, et al.
--
Bill Moyer <t...@rahul.net>
Patrick Gainer
Hamish Marson <ham...@waikato.ac.nz> wrote:
>Of couse so does an L2 cache (Whitness the difference between the 990
>and the R24 (Both RS6000's), the 990 has 256bit path to memory, and
>the R24 only a 128 bit path, also the 990 has 256kb data cache (L1) while
>the R24 only has 128kb, yet the R24 outperforms the 990 in tpm's by about
>50%).
Something to note is one cannot compare the tpmC rates directly
between the 990 and the R24 as different database systems were used.
The R24 runs and the SMP runs were done with DB2/6000 v2.1. I don't
know what was used for any 990 runs but it wasn't DB2/6000 v2.1.
Therefore, it is not clear how much faster in tp the R24 is over the
990 when using the tpmC metric.
Pat
Steven E. Bakke
announced? They are the ones based on the new 21164 chip. Oracle
also announced a version of their database software which is written to
fully take advantage of the '64-bitness' of the Alpha. The top-end
machine
has 12 CPU's running at 300MHz each and something like a gigabyte or more
dollars, it blows away IBM's $20 million mainframe.
I don't have specific figures available to quote, but the numbers that
were published were very good. I bring this up because it is a perfect
example of the advantage of 64 bits.
This advantage isn't only true for the top-end machines. The lower-end
machines beat virtually all the competition for price/performance.
I think of computing power like Field of Dreams - "If you build it, they
will come..." Similarly, if you build a much faster/more capable
computer,
somebody will find a way to max it out.
We will never have enough speed and power. Someone always finds a reason
to need more.
-Steve Bakke
University of Cincinnati
Lawson English
[snipt]
: However, from the Motorola home page, it doesn't look like there are
: fundamental differences in SMP support. It does look like there is more
: inherent parallelism in the MMU area but with the short descriptions
: provided who can tell? There is also no indication of "fundamentally
: different I/O support.
620 also has on-chip L2 controller, and has different VM support (I think).
It definitely was designed form SMP processing, but so was the 604.
Philip Machanick
> No you don't. However it makes it a lot easier to handle large amounts
> of data if your CPU is able to handle the large numbers involved natively,
> rather than in emulation. (FOr instance, a 64bit key comparison. Any key
> comparison for keys > 32 bits can be faster on a 64 bit machine than
> on a 32 bit machine, simply because you only need 1/2 the number of
> comparisons). Thats where transaction processing can really fly.
>
> Oh yeah. I don't know if the tpm;c I quoted above were for DB/2, the
> advertising doesn't say. But I believe they are done with the same
> data and RDBMS, so go a long way toward pointing out the speed defference
> between members of the RS6k family.
>
> > What will go the farthest in speeding up the transaction rate is high
> > memory bandwidth and low memory latency.
>
> True... Which the 128 bit memory interface on the 620 does wonders for.
> Of couse so does an L2 cache (Whitness the difference between the 990
> and the R24 (Both RS6000's), the 990 has 256bit path to memory, and
> the R24 only a 128 bit path, also the 990 has 256kb data cache (L1) while
> the R24 only has 128kb, yet the R24 outperforms the 990 in tpm's by about
> 50%).
I haven't seen anything yet in this discussion which wouldn't also be good
for fast graphics, high-end scientific computing and generally running big
programs fast. I wouldn't be surprised if MS Word 10 will need 64-bit
addressing :( Need for address bits tends to track improvement in RAM
density - if you can buy 4 times the RAM for the same price (which tends
to happen every 3 years), you tend to _use_ 4 times as much for similar
tasks. Word 6 which takes (I don't know, I don't have a copy) 10s of
megabytes on disk and needs several Mbytes of RAM and is reportedly slow
on a PowerMac. Word 1 ran reasonably fast on a 7MHz 68000 128K Mac
(minimum RAM partition 96K) and fitted on a 400K disk _with_ the Sytem
Folder and a few documents (it took up 123K on disk).
Will the same trend continue?
Taking a rough estimate of the growth in RAM requirement over the last 10
years for MS Word, it's increased by a factor of around 20. This is less
than the factor of increase in RAM density over the same period of about
64, but need for resources in MS products seems to be accelerating in
recent times.
For transaction processing, one important thing I have not seen mentioned
in this thread is efficient page translation with references widely
scattered in the address space. Do any of these processors have very large
TLBs or other strategies to reduce TLB misses? (A TLB is a usually small
cache of recent page address translations.)
--
Philip Machanick phi...@cs.wits.ac.za
Department of Computer Science, University of the Witwatersrand
2050 Wits, South Africa
phone 27(11)716-3309 fax 27(11)339-7965
Philip Machanick
(Patrick Gainer) wrote:
> Both 604 and 620 have 128 entry TLBs but the 620 also has
> a "64 entry, associative, effective-to-real translation cache". I
> wonder how this differs from a TLB? What is this caching that the TLB
> doesn't cache?
This partially answers my previous question. 128 entries in a TLB is not
particularly large (the MIPS R8000 has 384, and it's been in production
for a while now). I also don't know what the other thing is - maybe a 2nd
level TLB?
> The 604 has 16K, 4-way set associative I and D L1 caches while the 620 has
> 32K, 8 way set associative L1 I and D caches. High associativity and
> a 32K I cache would benefit TP loads.
This may be true but I imagine a big L2 cache would still be needed.
> However, from the Motorola home page, it doesn't look like there are
> fundamental differences in SMP support. It does look like there is more
> inherent parallelism in the MMU area but with the short descriptions
> provided who can tell? There is also no indication of "fundamentally
> different I/O support.
If each MMU has its own TLB, this could help in that programs with poor
locality (for example) on data may still have good locality on code. Also,
2 MMUs are probably essential to keep up the instruction throughput with
an aggressive superscalar design.
I still haven't seen anything in the 620 that woulsn't be good for general
high performance computing, not just transaction processing. I hope
someone comes up with hard information. The Byte November 94 article on
the 620 makes it sound more as if it's aimed at the high-end workstation /
number crunching market, and if anything says more in the MIPS R10000
(T5) article about transaction processing.
John Coddington
Patrick Gainer <gai...@gainer.engr.sgi.com> wrote:
>Both chips include on-chip logic for bus snooping (SMP).
The 6XX bus and the 60X bus are fundamentaly different. The 6XX bus
is really two busses, one for data and one for addresses. These buses
are separately arbitrated for and operations are tagged. The 60X bus
is not tagged. For instance, When the 620 wants to read some data, it
arbitrates for the address bus, and upon getting the address bus, it
request the block and assigns it a tag. The memory system upon
receiving the request, gets the data and then requests the data bus.
Upon being granted the data bus it puts the data on the data bus,
along with the tag the requesting 620 issued. The requesting 620,
since doing the read, has been watching all data bus operations. When
it sees its tag, it grabs the data. This is simplified, because I
didn't go into what happens with respect to snooping, but it does
point out one thing. Requests on the 6XX bus can be serviced
completely out of order, i.e. the 6XX bus device can issue a bunch of
reads, assigning each read a different tag, and get the data back in
an order completely different than how the request were made. This is
made possible by the tagging of operations.
To support the bandwidth of the 6XX bus, snooping is pipelined, unlike
on the 60X bus where only one snoop can be outstanding at one time.
On the 60X bus, if a read address needs to be snooped, the address
cannot retire from the bus until all snoopers have completed the
snoop, and issued their responses. This blocks other devices from
using the bus. On the 6XX bus, a new address can be presented every
other bus cycle, and the addresses do not hang around until the snoop
responses are issued. The address bus is not blocked for other
requestors.
Summing up, the 60X bus supports MP, the 6XX bus was designed for MP.
--
---------------------------------------------------------------------
John Coddington (I speak for myself) Phone: (512) 795-7035
jc...@ibmoto.com Fax: (512) 795-7513
---------------------------------------------------------------------
Michael Meissner
<chr...@power.globalnews.com> writes:
| OK, I'll bite. I'm sure that the 620's 64-bitness will be a totally splendid thing
| in terms of performance once there IS SOME SOFTWARE that uses it. Until
| then, it has absolutely no relevance, as far as I can see (other than being sure that
| you are ready for the future) I once asked IBM what kind of performance advantage you#
| would expecvt to see recompiling apps in 64-bit mode, to run on a 64-bit OS. I'm not sure I got
| a ver good answer.
If an application runs fine in 32-bit mode, recompiling it for 64-bit mode will
generally slow it down. The reasons include:
1) Pointers (and possibly integer variables) are now doubled in size.
This means the same size cache is now less effective (since there are
fewer things in it due to the size differences). This also tends to
make the amount of memory used by the program higher.
2) Multiply and divide are usually slower when dealing with 64 bits as
opposed to 32 bits (I haven't seen detailed docs for the 620 yet).
On the other hand, 64-bit generally gives you more address range. This allows
high end systems to put more than 4 gig of physical memory in the box. It also
allow more sparse addresses and such. If you do lots of multiprecision math
(such as crypto code), you can now have 1/2 the passes. Finally, it allows 64
bit file offsets to be handled reasonably without long long.
--
Michael Meissner, Cygnus Support (East Coast)
Suite 105, 48 Grove Street, Somerville, MA 02144, USA
meis...@cygnus.com, 617-629-3016 (office), 617-629-3010 (fax)
Chris Rose (PowerPC News)
>
> Tom Petersen (t...@nunez.ibmoto.com) wrote:
> > Mark Hendriks (mhhe...@zeno23.math.UWaterloo.ca) wrote:
> > : From: t...@wang.ibmoto.com (Tom Petersen)
> > : > What is the general perception of compatability across the PowerPC family.
>
>
> > Thanks for your input Mark, but I am really more interested in how
> > people view the 620 technically. Is 64-bitness a good thing? If
> > anyone likes the 620's 64-bit features, tell me what and why. What
> > are the customer expectations?
OK, I'll bite. I'm sure that the 620's 64-bitness will be a totally splendid thing
in terms of performance once there IS SOME SOFTWARE that uses it. Until
then, it has absolutely no relevance, as far as I can see (other than being sure that
you are ready for the future) I once asked IBM what kind of performance advantage you#
would expecvt to see recompiling apps in 64-bit mode, to run on a 64-bit OS. I'm not sure I got
a ver good answer.
Chris Rose
(PowerPC News)
Bill Moyer
Brian Cole <t...@dingo.cs.wisc.edu> wrote:
>
>Seriously, we're going to need 64-bit addressing eventually, and it makes
>sense to be ready. Now's not quite the time, but when the 620 is as cheap
>as the 601 is now, it might make sense to move to a 64-bit OS and not look
>back. (Actually, file systems need 64 bits right now.)
It's sooner than you think.. :-) We need 64 bit addressing right now!
I've been working on a database for my company that uses 64-bit logical
addresses, implemented on a 32-bit machine. It'll be nice to port it to
a 64-bit machine (our department is *very* enthusiastic about retooling
the lab with PPC-based systems).
Right now the code is written entirely in C++, and therefore completely
portable, but when I have a 620 on my desktop (or several with SMP) I'll
probably be able to talk my boss into letting me rewrite the inner-loop
code in assembly.
--
Bill Moyer <t...@rahul.net>
Matthew Pritzker
http://www.mot.com/PowerPC/, the PowerPC 620 doesn't have a 64-bit
address bus; it has a 40-bit address bus (1 TByte). Sure it's got
64-bit data registers, can support a 128-bit data bus, bur as I read
it, no 64-bit addressing.:(
+---------------------------+----------------------------+
| Matthew Pritzker | mpr...@umr.edu |
| Vice-President SPS-UMR | mpri...@umr.edu |
| Vice-President MAA-UMR | mpri...@physics.umr.edu |
| | http://www.umr.edu/~mpritz |
+---------------------------+----------------------------+
L S Diehr (Lawrence)
: ham...@waikato.ac.nz (Hamish Marson) wrote:
: >
: OK, I'll bite. I'm sure that the 620's 64-bitness will be a totally splendid thing
: in terms of performance once there IS SOME SOFTWARE that uses it. Until
: then, it has absolutely no relevance, as far as I can see (other than being sure that
: you are ready for the future) I once asked IBM what kind of performance advantage you#
: would expecvt to see recompiling apps in 64-bit mode, to run on a 64-bit OS. I'm not sure I got
: a ver good answer.
: Chris Rose
: (PowerPC News)
One advantage to the 64 bit fields is the ability to have 32 bit immediate data. There are
some advantages to be had here for speedups via optimizing compilers. Overall, I don't think
there will be any stupendous advantage for most applications. It would be interesting
if yjr 620 could fetch and process twice as many instructions at a time (compared to say
a 603e) due to the double wide nature of the pathways.
Larry DIehr
Tom Petersen
: ham...@waikato.ac.nz (Hamish Marson) wrote:
: >
: > > Mark Hendriks (mhhe...@zeno23.math.UWaterloo.ca) wrote:
: > > : From: t...@wang.ibmoto.com (Tom Petersen)
: > > : > What is the general perception of compatability across the PowerPC family.
: >
: >
: > > Thanks for your input Mark, but I am really more interested in how
: > > people view the 620 technically. Is 64-bitness a good thing? If
: > > anyone likes the 620's 64-bit features, tell me what and why. What
: > > are the customer expectations?
: OK, I'll bite. I'm sure that the 620's 64-bitness will be a totally splendid thing
: in terms of performance once there IS SOME SOFTWARE that uses it. Until
: then, it has absolutely no relevance, as far as I can see (other than being sure that
: you are ready for the future)
I agree. However, I want to emphasize your point about "being sure
that you are ready for the future". Very rarely will a new processor
feature be widely utilized by applications when that processor first ships.
These features migrate into the software base over time. Software will
always lag hardware.
If 620 was a 32-bit processor, 64-bit software would still be a
distant hope for PowerPC. Today, the 620 provides the platform to
develop the software base that is required for the eventual migration
towards a 64-bit environment.
Summing up, build the chip, and the apps will come.
:I once asked IBM what kind of performance advantage you#
: would expecvt to see recompiling apps in 64-bit mode, to run on a 64-bit OS. I'm not sure I got
: a ver good answer.
: Chris Rose
: (PowerPC News)
I don't believe there is a single answer to the question.
On the app side, program mileage will vary. Some apps will see very
significant performance improvements (things that can take advantage
of wide fix point operations...can you say graphics) , others will see
negilible improvement.
On the OS side, most apps will benefit from enhanced OS performance.
Larger address spaces will enable extremely large databases to be contained in
real memory, and potential OS overhead can be reduced by utilizing the
64-bit MMU features.
TAP
Brian Cole
]
] Thanks for your input Mark, but I am really more interested in how
] people view the 620 technically. Is 64-bitness a good thing? If
] anyone likes the 620's 64-bit features, tell me what and why. What
] are the customer expectations?
Yes, 64-bitness is a good thing indeed. First of all, it's just a nice
place, aesthetically, to live :-)
Seriously, we're going to need 64-bit addressing eventually, and it makes
sense to be ready. Now's not quite the time, but when the 620 is as cheap
as the 601 is now, it might make sense to move to a 64-bit OS and not look
back. (Actually, file systems need 64 bits right now.)
One could argue that a company like Apple, which was/is building its first
PPC OS from scratch (sort of) might want to build a 64-bit OS from the
ground up. Of course, Apple decided not to do this (can't blame them for
that, the 620s aren't here yet), but I hope they are taking the migration
to 64-bits into consideration and that it will be smoother than the 24-bit
to 32-bit migration they went through earlier.
brian
--
~~~~~~~~~~~~~~~~~~~ _______ _____ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Brian A. Cole |_ _ | | ___| visit Brian's Repository
U. Wisconsin | | | |__| |___ of Macintosh Information
t...@cs.wisc.edu |_| |__________| http://www.cs.wisc.edu/~tuc/mac/
Lawson English
[snipt]
: One could argue that a company like Apple, which was/is building its first
: PPC OS from scratch (sort of) might want to build a 64-bit OS from the
: ground up. Of course, Apple decided not to do this (can't blame them for
: that, the 620s aren't here yet), but I hope they are taking the migration
: to 64-bits into consideration and that it will be smoother than the 24-bit
: to 32-bit migration they went through earlier.
I could swear that the native version of the file manager is going to be
64-bit-ish...
Philip Machanick
Petersen) wrote:
> I agree. However, I want to emphasize your point about "being sure
> that you are ready for the future". Very rarely will a new processor
> feature be widely utilized by applications when that processor first ships.
> These features migrate into the software base over time. Software will
> always lag hardware.
I asked John Mashey why MIPS didn't go superscalar with the R4000 series.
His response was that they could only do one of 64-bit support or
superscalar with the component count they had to work with, and went for
64-bit. As a result they were able to work on a 64-bit version of UNIX in
time for when they needed it a few years later. These things need to be
planned ahead for some time. 32 bits is enough for now for personal
systems - but for how much longer?
Hamish Marson
> Just thought I'd point out that according to the stuff I read at
> http://www.mot.com/PowerPC/, the PowerPC 620 doesn't have a 64-bit
> address bus; it has a 40-bit address bus (1 TByte). Sure it's got
> 64-bit data registers, can support a 128-bit data bus, bur as I read
> it, no 64-bit addressing.:(
Userspace addressing is 64-bits, Virtual addresses are 80(?)
bits according to the book I have, and only the external
accessable PHYSICAL memory is currently limited to 1 Terrabyte
(40 bits).
Not much of a limit really....
Tom Petersen
: Matthew Pritzker (mpr...@hermes.cc.umr.edu) wrote:
: > Just thought I'd point out that according to the stuff I read at
: > http://www.mot.com/PowerPC/, the PowerPC 620 doesn't have a 64-bit
: > address bus; it has a 40-bit address bus (1 TByte). Sure it's got
: > 64-bit data registers, can support a 128-bit data bus, bur as I read
: > it, no 64-bit addressing.:(
: Userspace addressing is 64-bits, Virtual addresses are 80(?)
: bits according to the book I have, and only the external
: accessable PHYSICAL memory is currently limited to 1 Terrabyte
: (40 bits).
: Not much of a limit really....
I hope not. I expect that the RA restriction will be easily
contained in the VMM portion of an OS. When future PowerPC 64-bit chips
see a need for increased RA space, more bits can easily be added without
significant OS work. OS structure should not be affected by the 40 bit
RA restriction on 620.
Jim Wong
> It seems not! The only place I can see where this might be a
> screwup is in the massively parallel processing systems.. 1TB
> is quite enough for anything I can think of right now, but maybe
> a few years down the road you'll want to give each of your 4096
> processors more than 256MB of RAM.. That's kind of pushing it,
> though. The only reason I give it any thought at all is because
> of this nagging little voice in the back of my head that keeps
> saying: "640K is more memory than anyone will *ever* need!" :-)
If you were connecting 4096 processors, would you really be building a
shared memory system?
--
Jim Wong (jd-...@uiuc.edu)
Hamish Marson
Only if you had a really good cross-bar switch....
Bill Moyer
Tom Petersen <t...@zot.ibmoto.com> wrote:
>Hamish Marson (ham...@waikato.ac.nz) wrote:
>: Userspace addressing is 64-bits, Virtual addresses are 80(?)
>: bits according to the book I have, and only the external
>: accessable PHYSICAL memory is currently limited to 1 Terrabyte
>: (40 bits).
>
>: Not much of a limit really....
It seems not! The only place I can see where this might be a
screwup is in the massively parallel processing systems.. 1TB
is quite enough for anything I can think of right now, but maybe
a few years down the road you'll want to give each of your 4096
processors more than 256MB of RAM.. That's kind of pushing it,
though. The only reason I give it any thought at all is because
of this nagging little voice in the back of my head that keeps
saying: "640K is more memory than anyone will *ever* need!" :-)
--
Bill Moyer <t...@rahul.net>
John Harvey
>Jim Wong (jd-...@uiuc.edu) wrote:
>> In article <3na19g$r...@hustle.rahul.net>, Bill Moyer <t...@rahul.net> wrote:
>> > It seems not! The only place I can see where this might be a
>> > screwup is in the massively parallel processing systems.. 1TB
>> > is quite enough for anything I can think of right now, but maybe
>> > a few years down the road you'll want to give each of your 4096
>> > processors more than 256MB of RAM.. That's kind of pushing it,
>> > though. The only reason I give it any thought at all is because
>> > of this nagging little voice in the back of my head that keeps
>> > saying: "640K is more memory than anyone will *ever* need!" :-)
>> If you were connecting 4096 processors, would you really be building a
>> shared memory system?
>Only if you had a really good cross-bar switch....
This is way off topic, but Cray ran into this type of problem with alpha's
and there cray T3D. The Alpha's had only 43 bits for addresses (correct me
if you know better), and each Alpha had up to 128 Megs of local RAM(28 bits).
They systems have at least 1024 processors (10 bits) so you have only five
bits left for local memory or CPU's (32K CPU's or 8 ish gigs)
Tough life for some.
Later!
John Harvey (har...@sfu.ca)
Bill Broadley
: and there cray T3D. The Alpha's had only 43 bits for addresses (correct me
Alphas in the T3d have 34 bits for addressing.
: if you know better), and each Alpha had up to 128 Megs of local RAM(28 bits).
I believe it's 16 or 64 MB's per cpu. (twice that per PE)
: They systems have at least 1024 processors (10 bits) so you have only five
: bits left for local memory or CPU's (32K CPU's or 8 ish gigs)
Yes cray had to place a wrapper around the alphas to get addressability
of 2^37 bytes included on some of the T3d's.
--
Bill Broadley Broa...@math.ucdavis.edu UCD Math Sys-Admin
Linux is great. http://ucdmath.ucdavis.edu/~broadley PGP-ok
Brian Cole
]
] [snipt]
] : One could argue that a company like Apple, which was/is building its first
] : PPC OS from scratch (sort of) might want to build a 64-bit OS from the
] : ground up. Of course, Apple decided not to do this (can't blame them for
] : that, the 620s aren't here yet), but I hope they are taking the migration
] : to 64-bits into consideration and that it will be smoother than the 24-bit
] : to 32-bit migration they went through earlier.
]
] I could swear that the native version of the file manager is going to be
] 64-bit-ish...
It had better be 64-bit-ish, but it won't be able to take advantage of
^^^
the 64-bitness of the 620 chip becuase it also has to run on 60x chips.
Lawson English
: eng...@primenet.com (Lawson English) writes:
[snipt]
: ]
: ] I could swear that the native version of the file manager is going to be
: ] 64-bit-ish...
: It had better be 64-bit-ish, but it won't be able to take advantage of
: ^^^
: the 64-bitness of the 620 chip becuase it also has to run on 60x chips.
Since Apple is trying to make the entire OS (except for the 68K emulator)
as portable as possible by putting as much as possible into portable C
code, I don't think that the 64-bit-ness of the 620 is an issue, except
for optimizations -and they want the compiler to do those whenever
possible.
Now, memory management issues are more processor dependent, but I'd
expect that a 64-bit file manager could be completely independent of
whether the CPU is 32-bit or 64-bit for its addressing...
Evan Torrie
>> If you were connecting 4096 processors, would you really be building a
>> shared memory system?
>Only if you had a really good cross-bar switch....
Shared address space, distributed memory machines are being designed
now to handle those numbers of processors, so 64-bit addresses are a
concern.
--
------------------------------------------------------------------------------
<A HREF="http://liber.stanford.edu/~torrie/">Evan Torrie</A>.
Stanford University, Class of 199? tor...@cs.stanford.edu (finger for PGP)
"Men with a low opinion of mankind tend to have a high opinion of each other"
Nick Maclaren
|> In article <3n8bvk$o...@cerberus.ibmoto.com>,
|> Tom Petersen <t...@zot.ibmoto.com> wrote:
|> >Hamish Marson (ham...@waikato.ac.nz) wrote:
|> >: Userspace addressing is 64-bits, Virtual addresses are 80(?)
|> >: bits according to the book I have, and only the external
|> >: accessable PHYSICAL memory is currently limited to 1 Terrabyte
|> >: (40 bits).
|> >
|> >: Not much of a limit really....
|>
|> screwup is in the massively parallel processing systems.. 1TB
|> is quite enough for anything I can think of right now, but maybe
|> a few years down the road you'll want to give each of your 4096
|> processors more than 256MB of RAM.. That's kind of pushing it,
|> though. The only reason I give it any thought at all is because
|> of this nagging little voice in the back of my head that keeps
|> saying: "640K is more memory than anyone will *ever* need!" :-)
I currently have applications and code that could make use of more
than 1 TB of main memory, but I lack the bankroll to buy a suitable
system :-)
Nick Maclaren,
University of Cambridge Computer Laboratory,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email: nm...@cam.ac.uk
Tel.: +44 1223 334761 Fax: +44 1223 334679