Apple Job Posting and Good News for LinuxPPC developers
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
"Kevin B Hendricks" writes:
Kevin> Just in case anyone missed this. Apple is hiring someone whose job description Kevin> will include making it easier for people to get enough hardware info to get Kevin> Linux PPC to run on Apple's new hardware.
Kevin> We should get one of our own into this role and get a leg up on helping apple Kevin> open up its hardware specs for Linux PPC
My group at IBM Research also is looking for someone with operating
system development experience to join our project:
http://www.research.ibm.com/kitchawan/
The project is targeted at multiprocessor systems utilizing 64-bit processors including PowerPC64. An additional aspect is compatibility with glibc.
David
===============================================================================
David Edelsohn T.J. Watson Research Center [email protected] P.O. Box 218 +1 914 945 4364 (TL 862) Yorktown Heights, NY 10598
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]] [[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]] [[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
Quoted 10 lines
My group at IBM Research also is looking for someone with operating
system development experience to join our project:http://www.research.ibm.com/kitchawan/
The project is targeted at multiprocessor systems utilizing 64-bit processors including PowerPC64. An additional aspect is compatibility with glibc.
Do 64 bit PPC processors that can be bought as chips (not in a system) exist (i.e., can you buy a Power3 in a BGA package and the chipset that goes with) ?
Not many people have seen a 620 AFAICT :-( and the G4 I've seen announced by Motorola is not what I expected: it's a super 750 with Altivec + 604 FPU (single cycle double precision multiplier) + SMP capabilities.
But at least I expected:
- a 64 bit version (means >32 address pins, perhaps ~40 or so, 64 is obviously overkill right now and I don't ask for it)
- more superscalar (not 2+branch, but at least 4 way)
- longer in flight instruction queue
- 2 FPU: not sure, but divides seem to kill current PPC, one unit which can do all instructions(including sqrt) + one mult/add only would be great. OTOH, on FFT benchmarks which interest me also (not a single div), PPC are excellent.
- 2 LSU to feed all these units: hey Pentium and PPro can do 2 memory accesses por clock since they came out. They need it because they require many load/store to compensate for the small number of registers but I'd expect it to be beneficial even on PPC with large and fast backside L2 caches. Power2 has had 2 LSU since the beginning AFAICT.
Gabriel.
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]] [[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]] [[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Gabriel Paubert writes:
Gabriel> Do 64 bit PPC processors that can be bought as chips (not in a system) Gabriel> exist (i.e., can you buy a Power3 in a BGA package and the chipset that Gabriel> goes with) ?
I doubt it. The Power3 comes from the server organization and is
intended for their use. IBM, however, does understand customer demand:
if there was "enough" market interest, I am sure that it would find a way to sell it. The Power3 processor price is nowhere near a PPC750 or G4 and does not include AltiVec.
David
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]] [[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]] [[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
Quoted 8 lines
Gabriel> Do 64 bit PPC processors that can be bought as chips (not in a system)
Gabriel> exist (i.e., can you buy a Power3 in a BGA package and the chipset that
Gabriel> goes with) ?
Quoted 6 lines
I doubt it. The Power3 comes from the server organization and is
intended for their use. IBM, however, does understand customer demand:
if there was "enough" market interest, I am sure that it would find a way to sell it. The Power3 processor price is nowhere near a PPC750 or G4 and does not include AltiVec.
Actually I think the 64bit PPCs are called PowerPC II. They're reasonably nice chips last time I looked. They are expensive to put together in a system (ie 8MB L2, 128bit data bus, etc). Also the 6xx bus is a split transaction bus, so the bus controllers are a bit more complex too. I also think that all the data paths are ECC'd with parity on addresses. For a good example on what type of systems are built using these things, look at the S70 Advanced server.
TTFN - Guy
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]] [[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]] [[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Guy Sotomayor writes:
Guy> Actually I think the 64bit PPCs are called PowerPC II. They're reasonably Guy> nice chips last time I looked. They are expensive to put together in a Guy> system (ie 8MB L2, 128bit data bus, etc). Also the 6xx bus is a split Guy> transaction bus, so the bus controllers are a bit more complex too. I Guy> also think that all the data paths are ECC'd with parity on addresses. Guy> For a good example on what type of systems are built using these things, Guy> look at the S70 Advanced server.
64-bit PowerPC is an architecture, not a single chip. The first
implementation was the PPC620 from Somerset, eventually only used by Groupe Bull. The S70 and S7A use a chip from IBM Rochester also used in AS/400s. The Power3 (aka PPC630fp) is yet a third 64-bit PowerPC implementation. IBM's recent 64-bit PowerPC chips are augmented to support additional requirements of AS/400 systems.
David
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]] [[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]] [[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
Gabriel Paubert <[email protected]> writes:
[beefier PowerPCs]
Quoted 9 lines
Not many people have seen a 620 AFAICT :-( and the G4 I've seen announced by Motorola is not what I expected: it's a super 750 with Altivec + 604 FPU (single cycle double precision multiplier) + SMP capabilities.
But at least I expected:
- a 64 bit version (means >32 address pins, perhaps ~40 or so, 64 is obviously overkill right now and I don't ask for it)
I have heard rumours that the "Max" core has provisions to physically address more than 4GB of memory (via the MMU's segment registers). Processes would still be limited to a 4GB logical address space, though.
Quoted 2 lines
- more superscalar (not 2+branch, but at least 4 way)
The 604e is four-way superscalar, but it has slightly lower integer performance per clock cycle than the 750. Apparently you can't extract significantly more parallelism than 2 instructions per clock from real-world code, so the 604e's abilities are wasted, while the 750's exceptionally elegant branch handling leads to measurable benefits over the 604e's more traditional (though very sophisticated) branch prediction.
Quoted 2 lines
- longer in flight instruction queue
Compared to the 750, "Max" has additional reservation stations and a longer completion queue. Motorola's first estimates were 10% more integer performance per clock cycle than the 750, but this probably includes the effect of the larger L2.
BTW, a larger number of unresolved "in flight" instructions would jeopardize the processors unique (among superscalar CPUs) ability to directly execute branches without predicting them, because the outcome of branch conditions would more often be still "in flight", too.
Quoted 5 lines
- 2 FPU: not sure, but divides seem to kill current PPC, one unit which can do all instructions(including sqrt) + one mult/add only would be great. OTOH, on FFT benchmarks which interest me also (not a single div), PPC are excellent.
AFAIK, the divide algorithm used in PowerPC FPUs was selected specifically to re-use as much of the multiplier as possible; i.e. saving transistors was the foremost goal.
With nowadays silicon structure sizes, it would probably be a very good idea to have a separate divider. Possibly even one that uses a faster algorithm (like estimation plus refinement as is done explicitly in AltiVec).
Quoted 6 lines
- 2 LSU to feed all these units: hey Pentium and PPro can do 2 memory accesses por clock since they came out. They need it because they require many load/store to compensate for the small number of registers but I'd expect it to be beneficial even on PPC with large and fast backside L2 caches. Power2 has had 2 LSU since the beginning AFAICT.
AFAIK, Pentium and PPro/PII/PIII do not have the equivalent of two full-blown LSUs. In best case, they can do either two loads or one load plus one store, but not two store operations. Furthermore, their L1 cache is not really dual-ported, only dual-banked, so that two accesses can only be carried out in parallel if they hit different banks.
And finally, if you ever have an algorithm where loads or stores are the bottleneck, the performance will be limited by main memory bandwidth anyway, regardless of L1 bandwidth (unless you are register-starved, of course, but that will almost never happen with 32 GPRs + 32 FPRs (+ 32VRs)).
Holger
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]] [[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]] [[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Holger Bettag writes:
Holger> I have heard rumours that the "Max" core has provisions to physically address Holger> more than 4GB of memory (via the MMU's segment registers). Processes would Holger> still be limited to a 4GB logical address space, though.
The PowerPC architecture always has been able to address more than
32-bits of "logical" address space. That is the reason for the PowerPC terminology of "effective address", "virtual address", and "real address". The intermediate "virtual address" space of a 32-bit PowerPC implementation is 52 bits.
Pointers still are 32-bits, but a cooperating operating system and
compiler can allow an application to address more virtual memory through runtime modifications to the virtual segments mapped by the segment registers, like memory overlays. That was the original reason for the design of the MMU in the POWER (predecessor of PowerPC) architecture. I do not believe that any compiler / OS combination takes advantage of this facility.
David
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]] [[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]] [[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
Reoly to David Edelsohn, 4/2/99 12:11 PM -0500: Re: Apple Job Posting and Good News for LinuxPPC devel
Quoted 14 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Holger Bettag writes:
Holger> I have heard rumours that the "Max" core has provisions to physically address
Holger> more than 4GB of memory (via the MMU's segment registers). Processes would
Holger> still be limited to a 4GB logical address space, though.The PowerPC architecture always has been able to address more than
32-bits of "logical" address space. That is the reason for the PowerPC terminology of "effective address", "virtual address", and "real address". The intermediate "virtual address" space of a 32-bit PowerPC implementation is 52 bits.
Quoted 8 lines
Pointers still are 32-bits, but a cooperating operating system and
compiler can allow an application to address more virtual memory through runtime modifications to the virtual segments mapped by the segment registers, like memory overlays. That was the original reason for the design of the MMU in the POWER (predecessor of PowerPC) architecture. I do not believe that any compiler / OS combination takes advantage of this facility.
Only the IBM Mainframe and the AS/400 use windowed virtual storage to access more than 32 bits of address with 32 bit pointers. The IBM Mainframe can access a 44bit address range by using a 32 bit pointer as a base address for a 4k page boundry contiguous storage segment with a window size of up to 16meg. The old AS/400 did something similar to access it's virtual storage mapped database while the new AS/400 just switches to the PPC 64bit addressing mode and uses full 64bit pointers.
Thanx...
Doug
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]] [[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]] [[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
Quoted 8 lines · David Edelsohn
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Holger Bettag writes:
Holger> I have heard rumours that the "Max" core has provisions to Holger> physically address more than 4GB of memory (via the MMU's segment Holger> registers). Processes would still be limited to a 4GB logical Holger> address space, though.
Quoted 6 lines
The PowerPC architecture always has been able to address more than
32-bits of "logical" address space. That is the reason for the PowerPC terminology of "effective address", "virtual address", and "real address". The intermediate "virtual address" space of a 32-bit PowerPC implementation is 52 bits.
OK, that's true in the usual PowerPC terminology.
Quoted 1 line
Pointers still are 32-bits, but a cooperating operating system and
^^
That's what I meant with processes being limited to a 4GB logical address space, because the segment registers are not accessible with only user mode privileges.
Quoted 7 lines
compiler can allow an application to address more virtual memory through runtime modifications to the virtual segments mapped by the segment registers, like memory overlays. That was the original reason for the design of the MMU in the POWER (predecessor of PowerPC) architecture. I do not believe that any compiler / OS combination takes advantage of this facility.
Well, so far there are no 32bit PowerPCs that can handle more than 4GB of RAM. The rumours I heard indicate that "Max" might be able to handle more. That would make messing with segments worth the effort (and would generate all the neat problems of segmented addressing schemes).
Holger
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]] [[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]] [[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
Quoted 11 lines · Holger Bettag
Quoted 7 lines
compiler can allow an application to address more virtual memory through runtime modifications to the virtual segments mapped by the segment registers, like memory overlays. That was the original reason for the design of the MMU in the POWER (predecessor of PowerPC) architecture. I do not believe that any compiler / OS combination takes advantage of this facility.
Well, so far there are no 32bit PowerPCs that can handle more than 4GB of RAM. The rumours I heard indicate that "Max" might be able to handle more. That would make messing with segments worth the effort (and would generate all the neat problems of segmented addressing schemes).
There is no reasonable way a 32 bit PPC will handle more than 4Gb of physical RAM. However, with relatively simple patches, Linux could handle 4 Gb per process virtual address space and 3 Gb physical RAM on a 32 bit PPC.
Gabriel.
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]] [[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]] [[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
Quoted 6 lines · Holger Bettag
Quoted 3 lines
- a 64 bit version (means >32 address pins, perhaps ~40 or so, 64 is obviously overkill right now and I don't ask for it)
I have heard rumours that the "Max" core has provisions to physically address more than 4GB of memory (via the MMU's segment registers). Processes would still be limited to a 4GB logical address space, though.
This will be virtual and already exists. There is provision for 4Gb address space in the hash table defined for 32 bit processors and extending it is far too messy. Only a 64 bit PPC can be expected to have more than 32 address pins.
Quoted 8 lines
Quoted 2 lines
- more superscalar (not 2+branch, but at least 4 way)
The 604e is four-way superscalar, but it has slightly lower integer performance per clock cycle than the 750. Apparently you can't extract significantly more parallelism than 2 instructions per clock from real-world code, so the 604e's abilities are wasted, while the 750's exceptionally elegant branch handling leads to measurable benefits over the 604e's more traditional (though very sophisticated) branch prediction.
It depends of your definition of real world code. Floating point intensive scientific code is often extremely well behaved in this respect and could use more than 2 instructions/clock (as long as you don't call the math library for scalar transcendental operations).
Quoted 11 lines
Quoted 2 lines
- longer in flight instruction queue
Compared to the 750, "Max" has additional reservation stations and a longer completion queue. Motorola's first estimates were 10% more integer performance per clock cycle than the 750, but this probably includes the effect of the larger L2.
BTW, a larger number of unresolved "in flight" instructions would jeopardize the processors unique (among superscalar CPUs) ability to directly execute branches without predicting them, because the outcome of branch conditions would more often be still "in flight", too.
On PPC, with 8 CR fields, you can often prepare condition codes a long time in advance especially on scientific code. I've checked the code generated by GCC, and I often have 20 to 40 instructions between CR setting and actual branch (which are highly predictable BTW). Besides this the innermost loop is terminated by a bdnz when the iteration count can be computed beforehand. In this last case GCC does a bad job at optimizing the outer loop level but it's not that critical:
Loop not using ctr:
104: 7c 03 f0 40 cmplw r3,r30 108: 7c 78 1b 78 mr r24,r3 10c: 40 80 00 9c bge 1a8 <fftrtr+0x1a8> 110: 54 69 10 3a rlwinm r9,r3,2,0,29 114: 7c 09 b0 2e lwzx r0,r9,r22 118: 38 63 00 01 addi r3,r3,1 11c: 7c 03 f0 40 cmplw r3,r30
...
[snipped 33 instructions]
...
1a4: 41 80 ff 70 blt 114 <fftrtr+0x114>
Nested loops with bdnz on inner loop:
298: 7f 03 c3 78 mr r3,r24 29c: 7c 03 f0 40 cmplw r3,r30 2a0: 40 80 01 04 bge 3a4 <fftrtr+0x3a4> [Fair enough, 0 iteration count may actually happen, although it would be better to use r24 instead of r3 for cmplw] 2a4: 54 64 10 3a rlwinm r4,r3,2,0,29 2a8: 7c 04 b0 2e lwzx r0,r4,r22 2ac: 57 26 18 38 rlwinm r6,r25,3,0,28 2b0: 54 00 18 38 rlwinm r0,r0,3,0,28 2b4: 7c fd 02 14 add r7,r29,r0 2b8: 7d 07 32 14 add r8,r7,r6 2bc: 35 fa ff ff addic. r15,r26,-1 2c0: 7d e9 03 a6 mtctr r15 2c4: 41 82 00 d0 beq 394 <fftrtr+0x394> [Actually here the iteration count can never be zero but the compiler can't be blamed for not knowing it] 2c8: 7e 0c 83 78 mr r12,r16 2cc: 38 a0 00 00 li r5,0 2d0: 7d 9b 60 50 subf r12,r27,r12 ... [snipped 47 instructions] ... 390: 42 00 ff 40 bdnz 2d0 <fftrtr+0x2d0> 394: 38 63 00 01 addi r3,r3,1 398: 7c 03 f0 40 cmplw r3,r30 39c: 38 84 00 04 addi r4,r4,4
[Quite bad placement, neither r3 nor r30 are touched in the inner loop]
3a0: 41 80 ff 08 blt 2a8 <fftrtr+0x2a8>
I don't ask for 40 or 70 in flight instructions like PPro/K7, but something closer to the 604 (15-20). 6 is very little especially because it blocks the processor after divides (and the FPU is also blocked but it's the next paragraph).
And BTW, I know that a lot of code is not as predictable as scientific code but. I've written an Intel 486SX emulator which is the only code right now able to properly initialize my S3 video and there the branch density is significantly higher, indeed instruction dispatch and addressing mode decoding can probably be considered as a worst case in this respect. It's true that this code would not benefit a lot from much higher parallelism, but I consider it as non representative: it's a byte per byte interpreter which, at 24kB code+data, is small enough to be put in early boot code/Flash/whatever, and runs at a sufficient speed for this job on a 200MHz 603e (thanks to the fact that it does not thrash the cache).
However, even in this code the branch immediately following the CR setting instruction is the exception, 5 instructions are common. For indirect branches the ctr is typically set quite a lot of instructions before the branch (and there are other conditional branches in between anyway).
If you want to see the code, it is at:
ftp://vcorr1.iram.es/pub/linux-2.2/mvme2600.generic-patch-2.2.4 in the arch/ppc/prepboot directory.
Quoted 5 lines
Quoted 5 lines
- 2 FPU: not sure, but divides seem to kill current PPC, one unit which can do all instructions(including sqrt) + one mult/add only would be great. OTOH, on FFT benchmarks which interest me also (not a single div), PPC are excellent.
Quoted 7 lines
AFAIK, the divide algorithm used in PowerPC FPUs was selected specifically to re-use as much of the multiplier as possible; i.e. saving transistors was the foremost goal.
With nowadays silicon structure sizes, it would probably be a very good idea to have a separate divider. Possibly even one that uses a faster algorithm (like estimation plus refinement as is done explicitly in AltiVec).
At least we agree on that one. BTW, I wrote some time ago a square root routine which is much faster than the one currently implemented in glibc. Anyone wants to test it ? I was not able to prove mathmatically that it is fully IEEE compliant but I suspect so (and I can't test 2^53 possibilities. The code is free of divides and takes advantage of the intermediate 106 bit precision of fused multiply/add instructions).
Quoted 11 lines
Quoted 6 lines
- 2 LSU to feed all these units: hey Pentium and PPro can do 2 memory accesses por clock since they came out. They need it because they require many load/store to compensate for the small number of registers but I'd expect it to be beneficial even on PPC with large and fast backside L2 caches. Power2 has had 2 LSU since the beginning AFAICT.
AFAIK, Pentium and PPro/PII/PIII do not have the equivalent of two full-blown LSUs. In best case, they can do either two loads or one load plus one store, but not two store operations. Furthermore, their L1 cache is not really dual-ported, only dual-banked, so that two accesses can only be carried out in parallel if they hit different banks.
Pentium has (can even perform 2 stack pushes per clock of register and/or immediate values). P6 core (PPro/PII...) is 1 load + 1 store. Of course it's banked, but I would not care very much if it were implemented as in Power2, with special instructions which allow to load and store 2 FPR simultaneously. (even with alignment restrictions: with AltiVec, the HW to perform 16 byte load and stores is already there. I know it's more complex to implement when you need to access 2 different FPR, one of which may be ready and not the other, but it's great for complex arithmetic).
Quoted 4 lines
And finally, if you ever have an algorithm where loads or stores are the bottleneck, the performance will be limited by main memory bandwidth anyway, regardless of L1 bandwidth (unless you are register-starved, of course, but that will almost never happen with 32 GPRs + 32 FPRs (+ 32VRs)).
No, I want to saturate L2 BW, which is going to be in the 10 Gb/s range soon (500 Mhz @ 128 bit is 8Gb/s, double for 256 bit). With L2 caches larger than 1 Mb, my apps basically do not thrash L2 cache (and are even careful enough not to cause too many writebacks to it which could halve effective BW), provided it has enough associativity (4 way at least).
Besides that, 2 LSU would help in saving/restoring registers on procedure entry/exit (especially on 64 bit PPC since there is no lmd/stmd). But this is a side effect: if you worried about the overhead of procedure entry/exit, you've got other problems to cater first.
Gabriel.
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]] [[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]] [[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
Reoly to Gabriel Paubert, 4/5/99 6:06 PM +0200: Re: Apple Job Posting and Good News for LinuxPPC devel
Quoted 7 lines
No, I want to saturate L2 BW, which is going to be in the 10 Gb/s range soon (500 Mhz @ 128 bit is 8Gb/s, double for 256 bit). With L2 caches larger than 1 Mb, my apps basically do not thrash L2 cache (and are even careful enough not to cause too many writebacks to it which could halve effective BW), provided it has enough associativity (4 way at least).
With IBM recent announcement of Imbedded DRAM Macros for their Blue Logic library, the previous limits on L2 cache bandwidth no longer apply. IBM can deliver a G3 or G4 CPU with 2meg of imbedded DRAM as L2 with a 1024 bit wide L2 cache bus. This would allow a 4 way set associative cache with 4 simultaneous L2 cache transfers for read or write with a 2.5ns DRAM speed. The CPU die size would be only 50% larger and would only need 5 more mask steps. The cost of such a G3 or G4 CPU should be only 30% to 50% higher than current generation G3 CPUs, about the same as current Intel Pentium III CPUs. Combine this with the cache controller from the Power 3 CPU and IBM will be able to achieve between 8Gb/sec and 32Gb/sec L2 cache bandwidth. A 550mhz PPC G3 probably cannot even approach using that much bandwidth.
Thanx...
Doug
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]] [[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]] [[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]