Haha...Check this out.

http://www.ps3grill.com/

Don't take this seriously. Laugh about it.

I don't see what the fuss is about. That was a very balance analysis based on speculative data. Based on the speculative information, the XBox 360 does seems to be a more powerful beast compared to the PS3 or the Revolution.

I don't own a XBox and am myself a huge fan of Nintendo. But I can't deny the blatant fact slapped right at my face. But again this is speculative, so please hold your horses with titanium reins.

It's an analysis. Look at the charts, those are what you would find in an analysis.

Regarding the speculation of the Revolution spec, Nintendo did say that it's 2 or 3 times more powerful than GC.

Again, the analysis this is based on speculative data. Don't grill the presenter (IGN) if the data is inaccurate, grill Microsoft.

Ah... grill him then.

I couldn't agree more. It really gets me when people gets offended with certain analysis skewed towards a particular console. They're tonnes of it out there, one just need to take an unbiased stance and go through these articles objectively.

I seriously doubt Sony's approach of the PS3 core. 7 DSP (SPE) without L1 cache is unthinkable.

DSP are good at crunching data at high MIPS, in this case floating numbers. I would think that it would be prudent to at least have a data cache (D-cache). Without cache the bottleneck would likely be the access latency to the DRAM (whichever type it is). It just make more sense to have cache.

Well, we'll just have to wait and see how it goes.

EDIT: And no DMA too!!

This post has been edited by ray_: May 25 2005, 02:33 PM

I would have quoted from the same place. I don't see why you need to do this. You should discuss about the topic at hand knowing full well that the source is valid/invalid instead of having someone quote something that you've already read somewhere. You could have provided the link instead. Shame on you.

Please don't patronize.

EDIT: By the way, nothing is carved in stone currently. The thread comment reads speculative discussion, this is what it is, speculative. So please stop the "your source is wrong and my source is correct" argument unless you work for MS, Sony or PS3 next gen. console or have irrefutable prove that your source is correct. Or just leave it at that, speculative and enjoy the rebuttal.

This post has been edited by ray_: May 26 2005, 10:14 AM

Thanks for the link.

I'm not sure you could qualify the "Local Storage" as L1 cache yet. I would think that L1 cache access should be synchronized at core's frequency. We'll need to see if "Local Storage" is running at core frequency or other slower bus frequencies.

But you got one thing right. The SPE does indeed have DMA. There are no description however on whether the SMFs are DMAs. It would be nice to know if they have a dedicated DMA channel for each SPU or virtual DMA channels supported by a few physical DMAs.

You'll need to think SoC (System-On-Chip). With SoC, every friggin' peripherals are now on a die. But I do agree with your argument as I've made similar comment earlier, I don't see how this would work without L1 cache. But again I stress, until we see some clock distribution diagram, this is all speculative.

By the way, L2 cache does not necessarily run at core frequency. There are L2 cache that runs at lower frequencies such as that of the FSB. But L1 cache always runs at core frequency.

EDIT: I've read that you said recently. So yes, most recent L2 cache runs at core speed. But the question is, is the L2 cache in PS3 doing the same?

This post has been edited by ray_: May 26 2005, 12:37 PM

I'm an ignorant fool. Exactly what frequency is the PS3 core capable of?

Ah...I've forgotten my facts. Most recent DSP iteration has i-cache not d-cache. I apologize for my error.

One noteworthy point though. It's almost certain that the DMA of the SPE would be utilized for isochronous transfer (streaming data), thus off-loading the core. The DMA would most certainly have a reduced pipeline, removing redundant stages normally required in a CPU pipeline. There wouldn't be any need to fetch/execute any instructions at all.

Hate to reopen the can of worm marked expired.

But just to share my thoughts of the likelihood of "local storage" being cache. First, I do not think that IBM would called cache as local storage. I think local storage is more of a SPE internal RAM. An internal RAM would typically be refered to as a local storage.

Secondly, Having so many SPU units (8 in total based on the diagram), it would mean 256Kx8 L1 cache. A 2MB cache would bump up the price of the PS3 to preposterous level.

But I'm not claiming that the SPE has no L1 cache. On the contrary, I think that we might be looking at a very top level block diagram ( a macro view is you like ) and that the cache (if ever there be one) is embedded into one of this block (probably the SXU).

Again, I stress, this is all speculative. Constructive feedback welcomed.

At the time of writing I've also got this from gamespot:

1 Core, 7 x SPE 3.2GHz (256KB SRAM per SPE), 7 x 128b 128 SIMD GPRs
http://hardware.gamespot.com/Sony-PlayStation-3-15015-S-4-4

SRAM. If this is true, we could safely assert that the local storage is certainly not L1 cache. It could still be L2 cache, but I think it's most likely just that, internal RAM

Also spot this interesting bit after the above edit. On the L2 Cache row has this bit of info:
512KB L2 cache, 256KB per SPE

Yes, it's 1am and I'm still writing this shite.

This post has been edited by ray_: May 30 2005, 01:09 AM

It's too late to write a rebuttal. But do expect one in the morning.

First, let me get to some points:

1) I've suspected that the local storage is indeed not L1 cache.
If the tech. spec. at gamespot is anything to go by, thenI would say that my suspicion is correct. The local storage is infact a L2 cache according to gamespot.

2) I've suspected that the local storage is in fact internal memory.
Again, if gamespot is correct, then I would be wrong. Cell's "Local storage" isn't internal RAM. Although I agree that the line has blurred somewhat. I still think that there's a fundamental difference between RAM (memory) and cache. Cache has additional logic to invalidate, flush and enable/disable it's cells. Also the hybrid set-associative cache is only addressable by the CPU and "associates" each memory region of the cache with an equivalent region of the external RAM. Memory works differently to cache.

I do not think that cache is cheap. Cache, especially fast L1/L2 cache running at core frequency, are really expensive to make, but it does gets cheaper as the technology improves. That is why there is so very little of cache RAM available on all off-the-shelf processors. If you goggle "cache" and click through the result, it would almost always be tagged with the word "expensive".

Although it might be densely packed, cache would still take a large portion of the die. The Cell has a 512K L2 cache. Look at how much space it requires on the die layout.

Again, thanks for the wonderful link.

My fixation on the L1 cache was due to your claim that "Local storage" was infact a L1 cache. Which has now been proven to be incorrect. I think you should give me that much.

I share some of your argument on my most recent post (eg. the fact that cache is not directly addressable by the user). Please read em' and see if you'd agree.

Reading the document, it looks like the SPE has no cache at all. And that the local storage is rather quite simplistic in design. And also that Gamespot is inaccurate in labeling local storage as L2 cache.

I think here's how it would work:

- Prior to running a specific process on the SPE, all instructions and data required for the process would need to be copied to the SPE local storage via the PPE MMU. This should be done either autonomously by a robust compiler (supplied by the PS3 dev. kit) or by the programmer (gasp...).

There are no mentions of the speed at which the SRAM is running. But since SRAM are traditionally asynchronous, there would be wait cycles required for read and write accesses.

There are also no mentions on whether the SPE DMA could directly address external memory space or I/O address space to transfer instruction or data from external memory or I/O memory mapped peripherals to the local store.

This post has been edited by ray_: May 30 2005, 11:58 AM

I do agree that cache miss is expensive. But it must be said that the SPE would still be benefiting from some form of cache implemented sensibly.

We all agreed that there's no need for a D-cache. But adding an I-cache could enhance the throughput of the SPE based upon these assumption:

1) I've never implemented or seen a graphic processing algorithm before, but I would assume that it would need to process acquired buffered real-time data (either acquired through the CPU or DMA). Since the SPE is not designed to have a resident RTOS, instead of having multiple tasks waiting on mutexes/semaphores synchronized to the acquisition of these data, it would most probably be synchronized to an IRQ. The acquired real-time data should be synchronous, thus the IRQs should be fired periodically and at deterministic intervals. With a 256K of internal storage, there should be minimal cache miss (cache fill) if the cache is large enough (16k?) and has a suitable block and set distribution, and the executable image has a small enough footprint.

2) Unlike DSP required for network protocol processing, which branches frequently (to service hardware interrupt, software interrupt or task switch), the access pattern of a graphic processing application should be more predictable. Thus could be sensibly distributed and optimized to minimized cache miss. The CPM module of the PowerPC would be used for protocol handling.

I've made I-cache evaluation on certain DSP. And I must say, even with large executable image and unpredictable access pattern, we could still register some throughput improvement compared to accessing plain old RAM (although it must be said that as the size increases and pattern becomes unpredictable, the access time grows drastically). Now, compare running code at RAM speed most of the time and running code at core speed sometime and RAM speed at others, it's not hard to see which is better.

My 2 cents.

Sorry but could only skim through the ars-technica article. I could only see that this could be a non-issue if the 256K LS is synchronized to core frequency but has none of the typical cache function, as stated in the article, such as tag and cache coherency/snooping logic (i.e. having the speed of a L1 cache but not the redundancies associated with it). Can we assume that much?

EDIT: Nevermind. Got my answer. No assumption required. The 256K is indeed synchronized at core frequency. Now, that's one %@^&#^ SRAM.

EDIT2: There's a fundamental flaw in my argument. Nobody caches internal RAM. Now let me wallow in my pool of ignorance. (* splash..splash)

This post has been edited by ray_: Jun 2 2005, 04:06 PM

Great read and good post.

Now for the customary bait to lure massive tech. flames:

Comments on my part:
1) If I'm not mistaken, branch prediction would never work for IRQ. Thus with PPE's deep 21 stages pipeline, there should be much pipeline stall (pipeline flush) if the PPE were to run interrupt prone tasks (eg. protocol related, TDMA...etc.). The XBox would need to handle a couple of network related processing such as WIFI and Ethernet, presumably using dedicated hardwares on the CPM module.
2) Another one of those single-threaded task would be this:
while(1)
{
printf("Hello 4TW\n");
}
But I do not think noobs would be programming for large gaming companies.

Anyone know if the MPx or the 60x bus is used as inter-processor bus? And if there's an internal RAM on each PPE like the DPRAM in previous PowerPC?

Hey, ikanayam. Yep, there are caches. But I was looking for internal RAM such as that on the SPE.