ppc and ppc64 packages - why both?

[florin]

I'm looking at a repository for Fedora 6 PPC (usable with YDL6) and I noticed that it has ppc and ppc64 packages. What's the difference? Are the ppc packages 32 bit?

I tried to rebuild a src.rpm on YDL6 on PS3, and the system attempted to create a ppc64 package. Why it chose ppc64 and not ppc?

[billb]

I'm looking at a repository for Fedora 6 PPC (usable with YDL6) and I noticed that it has ppc and ppc64 packages. What's the difference? Are the ppc packages 32 bit?

I tried to rebuild a src.rpm on YDL6 on PS3, and the system attempted to create a ppc64 package. Why it chose ppc64 and not ppc?

Try this:

Code: Select all

setarch ppc rpmbuild --rebuild --ppc yourfile.src.rpm

[ppietro]

I'm looking at a repository for Fedora 6 PPC (usable with YDL6) and I noticed that it has ppc and ppc64 packages. What's the difference? Are the ppc packages 32 bit?

I tried to rebuild a src.rpm on YDL6 on PS3, and the system attempted to create a ppc64 package. Why it chose ppc64 and not ppc?

Yes - the PPC packages should be 32 bit.

Not sure why the PS3 chose 64 bit for rebuilding rpms. I still haven't loaded YDL 6.0 yet, so I don't know what the defaults are, but 5.0.2 tried to manually set the compiler flags to 32 bit. At least, it would generate 32 bit code when doing straight C code compiles. (i.e. "Hello World").

Unlike x86_64 architecture computers, there's no real benefit to running PPC 64 code on the PS3, due to the limited memory space. There might possibly even be a slight speed penalty due to the 64 bit overhead.

Cheers,
Paul

[florin]

Unlike x86_64 architecture computers, there's no real benefit to running PPC 64 code on the PS3, due to the limited memory space. There might possibly even be a slight speed penalty due to the 64 bit overhead.

But isn't the Cell (well, the PowerPC part of it) 64 bit? If so, wouldn't there be a performance penalty inherent in running 32 bit code on it?

[ppietro]

But isn't the Cell (well, the PowerPC part of it) 64 bit? If so, wouldn't there be a performance penalty inherent in running 32 bit code on it?

Actually no. The opposite - at least for PPC.

The trick is internal register sizes. When the PPC is running 32 bit code, the internal registers and address space pointers are only 32 bits long. Moving 32 bits chunks of data around from processor to main memory is pretty speedy. When you run 64 bit code, all the registers increase their size, but the pipe remains the same. So - for a constant into a 64 bit register, you'd load 32 bits, shift, then load 32 bits again. Now, all of the 64 bit operations take just a little bit longer.

You can still do 64 bit operations in 32 bit code, so you don't lose anything that way.

If you look at this presentation http://lixom.net/~olof/lca.pdf, you'll see this on the 12th slide:

Code: Select all

Kernbench results:

PPC:
   Elapsed time 208.69
   User Time 378.95
   System Time 34.812

PPC64:
   Elapsed time 253.47
   User Time 452.784
   System Time 49.934

PPC64 20% slower!

Contrast this to the x86 results:

Code: Select all

x86:
   Elapsed Time 162.612
   User Time 293.356
   System Time 29.108

x86_64:
   Elapsed Time 126.67
   User Time 219.252
   System Time 27.288

x86_64 27% faster!


Why is this? Because, unlike PPC, x86_64 actually changes the structure of the processor - adding new registers and new instructions when you jump to 64 bit. The penalty incurred by the increased 64 bit overhead is nullified (and improved) by the new processor extensions.

Cheers,
Paul

[florin]

Why is this? Because, unlike PPC, x86_64 actually changes the structure of the processor - adding new registers and new instructions.

Wow. In other words, 64 bit on PPC (at the processor architecture level) is just a lazy hack.

[ppietro]

Wow. In other words, 64 bit on PPC (at the processor architecture level) is just a lazy hack.

Something like that.

Cheers,
Paul

[ACEFOMIQUZ]

But isn't the Cell (well, the PowerPC part of it) 64 bit? If so, wouldn't there be a performance penalty inherent in running 32 bit code on it?

Actually no. The opposite - at least for PPC.

The trick is internal register sizes. When the PPC is running 32 bit code, the internal registers and address space pointers are only 32 bits long. Moving 32 bits chunks of data around from processor to main memory is pretty speedy. When you run 64 bit code, all the registers increase their size, but the pipe remains the same. So - for a constant into a 64 bit register, you'd load 32 bits, shift, then load 32 bits again. Now, all of the 64 bit operations take just a little bit longer.

You can still do 64 bit operations in 32 bit code, so you don't lose anything that way.

If you look at this presentation http://lixom.net/~olof/lca.pdf, you'll see this on the 12th slide:

Code: Select all

Kernbench results:

PPC:
   Elapsed time 208.69
   User Time 378.95
   System Time 34.812

PPC64:
   Elapsed time 253.47
   User Time 452.784
   System Time 49.934

PPC64 20% slower!

Contrast this to the x86 results:

Code: Select all

x86:
   Elapsed Time 162.612
   User Time 293.356
   System Time 29.108

x86_64:
   Elapsed Time 126.67
   User Time 219.252
   System Time 27.288

x86_64 27% faster!


Why is this? Because, unlike PPC, x86_64 actually changes the structure of the processor - adding new registers and new instructions when you jump to 64 bit. The penalty incurred by the increased 64 bit overhead is nullified (and improved) by the new processor extensions.

Cheers,
Paul

Maybe there was some other reasons that caused the results:the GCC C ppc64 compiler might not have played the performance of the PowerPC 970 processor.There would be a better result if we use IBM Rational XL C/C++ compiler for the 64bit-PowerPC architecture processors.
C and C++ Compilers
For PowerPC-64bit on Linux
For CellBE on Linux

[ppietro]

Maybe there was some other reasons that caused the results:the GCC C ppc64 compiler might not have played the performance of the PowerPC 970 processor.There would be a better result if we use IBM Rational XL C/C++ compiler for the 64bit-PowerPC architecture processors.
C and C++ Compilers
For PowerPC-64bit on Linux
For CellBE on Linux

Nope - not at all. It's the inherent limitations in the original 64 bit PowerPC architecture - pure and simple.

The slide show I posted was not speculation. Take a closer look at it:

http://lixom.net/~olof/lca.pdf

It was from P.A. Semi. These folks were one of the few places authorized to make PowerPC processors, outside of Apple/IBM/Motorola. You can read more about them here:

http://en.wikipedia.org/wiki/P.A._Semi

Here's a description of what they did:

P.A. Semi concentrated on making powerful and power-efficient Power Architecture processors called PWRficient, based on the PA6T processor core. The PA6T was the first Power Architecture core to be designed from scratch outside the AIM alliance (i.e. not by Apple, IBM, or Motorola/Freescale) in ten years. Texas Instruments was one of the investors in P.A. Semi and it is suggested that their fabrication plants will be used to manufacture the PWRficient processors.[5]

PWRficient processors are currently shipping to select customers and were set to be released for worldwide sale in Q4 2007.[6]

Unfortunately - all these plans ended after P.A. Semi's acquisition by Apple Computer.

Cheers,
Paul

[ACEFOMIQUZ]

In fact,i really don't know why IBM had developed such a low efficent 64-bit processor for taking place the past generation 32-bit processor.
Do you want to say there is the same thing that happening on the POWER architecture?POWER32<POWER64

[ppietro]

In fact,i really don't know why IBM had developed such a low efficent 64-bit processor for taking place the past generation 32-bit processor.
Do you want to say there is the same thing that happening on the POWER architecture?POWER32<POWER64

I can't speak to true POWER chipsets. Their architecture is different from PowerPC.

As for why the first generation ppc64 chipsets were designed like that? I think - stress think - it might be due to power (i.e. wattage) consumption. The Power970 line - i.e. the Apple G5 - were architected down from IBM POWER4 chipsets, not designed by Motorola like the previous generation PowerPC 7400 series - i.e. the Apple G4.

From here:
http://en.wikipedia.org/wiki/PowerPC_970

The 970 family was created through a collaboration between IBM and Apple. The project went under the codename GP-UL or Giga Processor Ultra Light, where Giga Processor was the codename for the POWER4 from which the core was derived. When Apple introduced the Power Mac G5 they stated that this was a five year collaborative effort, with multiple future generations, but it was short-lived. Apple had to retract the promise to deliver a 3 GHz processor one year after its introduction and IBM could never get the power consumption down far enough for these processors to fit into a portable computer.

and here:
http://en.wikipedia.org/wiki/PowerPC_G4

Much of the 7400 design (aka G4) was done by Motorola in close co-operation with Apple and IBM. IBM, the third member of the AIM alliance, did design the chip together with Motorola in its Somerset design center, but chose not to manufacture it, because it did not see the need back then for the Vector Processing Unit. Ultimately, the G4 architecture design contained a 128-bit vector processing unit labelled AltiVec by Motorola while Apple marketing referred to it as the "Velocity Engine".

Now - the interesting question is "Where did the Cell's PPE come from?" The way I interpret the book "The Race For A New Game Machine", by Shippy, et al, the PPE is not derived directly from POWER4. Shippy says that the Austin team was designing the PPE for Apple/Sony/Microsoft, and due to removal of "out-of-order" processing to make Sony & Microsoft's console deadlines, Apple jumped from the Austin design center to one of IBM's server teams for the G5.

I understand this IBM server team would have been the POWER4 team. The Austin team's PowerPC core would have been similar to the one used in the G4, not POWER4 based, if I understand the book correctly. (i.e. the difference between a PC team and a Server team, in IBM-speak)

So - it's conceivable that the PPE may handle 64 bit somewhat differently than the G5. However - I'd have to do more research to find out how.

Cheers,
Paul

[ACEFOMIQUZ]

Thanks very much! You've finally given me a satisfactory answer!

[ppietro]

One more thing.

From http://en.wikipedia.org/wiki/Powerpc#Operating_systems

Note that a 64-bit PowerPC application which does not need 64-bit math will run slightly slower than if it were compiled in 32-bit mode. This is because 64-bit pointers and longs consume twice as much memory as their 32-bit counterparts, so the CPU cache will be able to hold less data and memory accesses will be more frequent. This is typical for 64-bit processors: the only significant exceptions are those like the DEC Alpha where all operations are 64-bit and "32-bit mode" is really just a choice of instructions, and the Intel 64/AMD64 architecture where only 8 registers are available in "legacy" 32-bit mode, while 16 are available in the 64-bit mode,[4] an increase which can speed up procedures with large numbers of local variables and cut down memory accesses. Therefore it is not necessary to run a fully 64-bit operating system on a 64-bit PowerPC system; you obtain virtually all of the advantages of the 64-bit architecture by using a 64-bit kernel with 32-bit system software. A tiny minority of software requires a 64-bit build, typically those dealing with >3 GB of virtual memory or 64-bit integer math.

[4] "Porting Code to Intel EM64T-Based Platforms". Intel.com. http://www.intel.com/cd/ids/developer/a ... htm?page=2 . Retrieved 2009-08-16.

So - it's not just internal pipelines like the PA Semi article indicates, but cache size as well.

Cheers,
Paul