the core is myth thats what i know and i think the quad cores are far better than it .. see how it can run Crysis in the PC without using it full power or even 60% of its power.

NNN2004 said: the core is myth thats what i know and i think the quad cores are far better than it .. see how it can run Crysis in the PC without using it full power or even 60% of its power.

I wonder can X360 or PS3 even run AI for crysis real time. They aren't the best platforms for such a job.

 

selnor:

I watched your signature for a while and I just don't get that macho stuff. Its just stupid to inform own position for enemies before engaging them. :)

 

Deneidez said: NNN2004 said: the core is myth thats what i know and i think the quad cores are far better than it .. see how it can run Crysis in the PC without using it full power or even 60% of its power. I wonder can X360 or PS3 even run AI for crysis real time. They aren't the best platforms for such a job.   selnor: I watched your signature for a while and I just don't get that macho stuff. Its just stupid to inform own position for enemies before engaging them. :)

Yeah LOL. You obviously havent played it then. You need to play it to understand the context of whats happening. :)

 

^ True. But shooting a locust/predator thingee in the ass with your Lancer would probably get its attention just as well.

NJ5 said: @selnor: Actually that's not correct, the SPEs can run any C code and are Turing-Complete. Now as for running that code efficiently, that's another story entirely...

Yes, that's true.  But it's also possible to use a GPU to do some CPU work and I've seen programmers make SQL code actually do math, but both are very difficult and not very effective just like using an SPE for general purpose CPU code isn't very effective.  SPEs are designed to do transforms, etc. on data.

 

crumas2 said:   SPEs/SPUs are not general purpose CPU cores.  They're specialized execution units that are very good for manipulating large amounts of similar data in useful and interesting ways.  Think bit-blitter or DSP on steroids.  They're very good at pre-processing video information before sending it to a GPU. This is one of the reasons they're difficult to program, because it's not like programing a traditional CPU core. They're better suited than a CPU for same tasks, and worse suited for others. And I wouldn't invest too much energy in IBM's promotional "tech" literature... they will always try to paint their architecture in the best light by pointing out where a specific theoretical spec is better than the competition's.  The reality of what the system can be used for is almost always more complicated. This all said, yes the PS3's architecture (not just the Cell) is very powerful in many ways, but it still doesn't have 8 cores.

You should really avoid commenting on this, since you have, quite obviously from this comment, never worked on a PS3, or at least never with the SPUs.  I can say with authority that the italicized parts of the comment above is pure BS, and the sources you got it from don't know what the hell they are talking about.  The SPUs *are* general purpose cores, with a lot of extra logic devoted to vector mathematics.  They lack the supporting memory architecture to do things in the same manner as the PPU, but that doesn't stop them from being able to do it.  Being an independant core doesn't require that you be able to address main memory directly -- the only requirement is that the processor be able to run concurrently with other cores.  The SPUs can, and frankly they can run general purpose code, that doesn't involve accessing large tracts of memory (which is a big deal), just as fast, or in some cases faster, than the 2 hardware PPU threads can.

The bolded part of your comment is absolutely correct, however.  At least you got that right -- or your source did.  The only reason any newbie engineer wannabe could possibly claim that the SPUs are "not independant cores" is due to the fact that they can only address their 256K local memory (not a "cache" as some have called it), and must stream data from main memory in/out.  The truth is, however, they can do this independantly of the PPU.  Thus *drum roll* they are independant cores.  They are NOT coprocessors, as you seem to be implying, as that's the word used to describe a "dependant processor" which isn't actually capable of independant operation.  The SPUs are -- thus, they are independant cores.  

I know you aren't going to be able to say to someone who doubts this fact "Groucho said that's not true", but I can tell you that, if you understand that the SPUs are independant cores, you will be correct, and anyone who says otherwise is... well, ignorant, and full of... balogny.  Please have faith that some authorities do surf here, and please stop peddling this kind of hogwash.

 

Groucho said: The SPUs can, and frankly they can run general purpose code, that doesn't involve accessing large tracts of memory (which is a big deal), just as fast, or in some cases faster, than the 2 hardware PPU threads can.

That's not true. There are some specific ways in which the SPUs are inherently slower than the PPU, for example double-precision arithmetic.

Do the math and you can see the PPU is 3.5 times faster than the SPU at that.

Source:

http://www-128.ibm.com/developerworks/power/library/pa-cellperf/

 

NJ5 said: Groucho said: The SPUs can, and frankly they can run general purpose code, that doesn't involve accessing large tracts of memory (which is a big deal), just as fast, or in some cases faster, than the 2 hardware PPU threads can. That's not true. There are some specific ways in which the SPUs are inherently slower than the PPU, for example double-precision arithmetic. Each SPU is capable of executing two DP instructions every seven cycles. With Fused-Multiply-Add, an SPU can achieve a peak 1.83GFLOPS at 3.2GHz. With eight SPUs and fully pipelined DP floating-point support in the PPE's VMX, the Cell BE is capable of a peak 21.03GFLOPS DP floating-point Do the math and you can see the PPU is 3.5 times faster than the SPU at that. Source: http://www-128.ibm.com/developerworks/power/library/pa-cellperf/

There may be a few operations where a 3.2 GHz SPU is slower than a 1.6 GHz PPU thread, but in terms of general-purpose programming, its negligable.  Even branches tend to be faster on the SPUs, and that's practically the definition of "general-purpose" programming expense.

 

@ Jo21

That's Microsoft marketing, not IBM's.

IBM stated 76.8 GFlops for the Xenon, an explanation by a knowledgeable buddy tech writer Nicholas Blanchford:

"Love to know how they managed that ...it's peak is only 76.8 GFLOPs.

The 115.2 figure is the theoretical peak if you include non-arithmetic instructions such as permute. These are not normally included in *any* measure of FLOPs.

As for being measured, where? I've never seen any 360 benchmarks and can't find any.

If you want to count non-arithemitic peak figures, the usable Cell components in the PS3 will get 268 Gflops (6 SPEs + PPE) - over twice that of the 360."

Note however the Xenon is never going to be near its theoretical max, unlike the Cell which has been demonstrated to be near 100% efficient, each additional SPE is able to achieve a near linear performance increase.

Second note, the PS3 Cell has 7 SPEs instead of 6 regarding to what Nicholas mentions above. 1 SPE is being used by the PS3 OS, uses for which the OS will not waste CPU cycles on the other processors for.

Groucho said:  Even branches tend to be faster on the SPUs

How is that possible if the PPU has dynamic branch prediction and the SPU doesn't?

Source

Correct me if I'm wrong, but that's two false claims in a row from you...