@ CrashMan
While working with the Cell's SPEs, you will work with continuous feeds of datachunks, this is not a major limiting factor and a reason why the EIB bandwidth is so high. If you have larger chunks (which would be a lot of data!), then you just need to break it up. The store size does not limit the amount of work you can do, just the amount of work you can do at a time. I guess many devs are used to this approach as the PS2's VUs only had 4k/16k on them.
Also to quote Beyond3D staff: "People don't seem to realize how much 256 KB is, in this age of 1/2 GB RAM - there's no context. 256 KB is as much as the original Amiga launched with; a computer that could do graphics, word-processing, music editing, ray-tracing etc. It's memory was limiting, mostly because you didn't have much room for data. There weren't any applications it couldn't do due to lack of room for code."
For our youngsters who don't what an Amiga is:
http://youtube.com/watch?v=yckH20ngY4Y (cheesy 80's clip)
http://youtube.com/watch?v=qSA-q1qniMY (what AmigaOS is today running on old computers, including those well over a decade old)
256 KB of code is an extraordinary amount for a task. Unless you're trying to run full applications (and you could get a nice graphics editor into 256 KB...) with zillions of features, your greatest concern by far will be streaming data."
I had a somewhat similar discussion in here with regard to main memory, with me explaining that the main memory is more than large enough for the long run while streaming more data such as textures (an important technical game engine difference between R&C TOD and Resistance, the latter probably only streamed audio) and Blu-Ray disc giving the PS3 the advantage of being able to stream much more data.
