forums.ps2dev.org

[ooPo]

YDL 5.0 on a 20GB PS3:

[wulf]

sweet, thanks, oopo!

[Herben]

I see you use 1080p, does that work out well for you? I have a hard time reading text at that res though I like the extra screen space. ;P

[ooPo]

I'm using a pc monitor with hdcp, so its very sharp. No problems at all.

[panda21]

Am I right in thinking that the first section means the PS3 has a dual core PPC main processor where each core is 3ghz?

I have Gentoo on my 60gb PS3 and tried some of the benchmarks from the computer language shootout page on it.

I know these are just benchmarks, they'll only be using one core, and they aren't optimized to run on the SPU's etc, but running pidigits in python, and spectral norm in C on my OS X 1.5ghz G4 powerbook comes out pretty much the same speed as in Gentoo on my PS3.

Surely they should be faster if theyre running on a 3ghz processor? Are the PS3 main processors significantly different from a mac ppc processor?

[jimparis]

[wich]

The PPC core in the CBE is very very different from the PPC in a Mac. The most important difference is that the PPC core in the CBE does not have an instruction window and only very limited bracnh prediction.

The instruction window of a processor looks at the the next n instructions to be executed and reorders them in order to take maximum advantage of parallelisation of instructions on the various processing units in the core. In short a properly functioning instruction window can greatly increase the number of instructions executed per clock cycle. The penalty however is that the instruction window takes up much die real estate, which in the case of the CBE is spent on the SPEs instead. The rationalization for this is that the proper reordering of instruction can also be done in the compiler, but this of course means that the compiler should have an intimate knowledge of the processors internal workings to determine the proper order of instructions. Given however that the CBE is a specialized processor, and not bound to any previously defined computing platform this isn't much of an issue beyond the actual effor to realise such a compiler.

The branch prediction is a very complicated piece of kit in most modern processors. It's task is to predict which code branch will be taken well before the actual branch instruction is executed. The reason for this is that when the prediction is wrong, the processor has to clear the entire instruction pipeline and restart processing with the branch actually taken. Given that these days instruction pipelines are getting very long, such a branch miss will incur numerous wasted processor cycles which the processor needs to refill the instruction pipeline. Again though the branch prediction takes up a lot of die real estate which in the case of the CBE is contributed to the SPEs instead. Again the rationalisation here is that the compiler can hint the processor which branch will be taken in an upcoming branch instruction by inserting branch hints in the instruction stream.

In the end all of this means that code generated by a run of the mill compiler will run far more inefficiently on the CBE's PPC core than on a G4 or G5 PPC. In order to use the true processing power of the CBE you need a specialised compiler.

There are quite a few more differences, but these are the most important ones in this respect.

[J.F.]

[panda21]

thanks thats a really good explanation, i thought it might be something like that. hopefully there'll be better compilers for it eventually!

[wich]

You are right in saying that older PPC processors also did not have very complicated instruction windows and branch predicition, but the rest of the core is very much modelled after more recent PPCs.

People interested in these kinds of things should read the Ars Technica articles on the Emotion Engine, the CBE and the Xenon CPU, they are very interesting reading material.