I am not sure "flexible" is the right word, at least at how I look at the processors. It really depends what you are looking at in the designs.
Per the caches, I would not necessarily disagree. Looking at the caching setup on the XeCPU I can see where it would be more limiting, but that I think it is tradeoffs of a multicore PPC design versus a streaming processor. The flexibility with the SPEs is a necessity of the CELLs streaming design as you need to do a lot of operations on a small amount of data to benefit from a stream processor. So l look at it more as design feature that the multicore PPC does not necessarily need. The XeCPU does seem to be "less flexible" with how it can "lock" for procedural synthesis (compared to how the CELL PPE and SPEs look to use the FlexIO pretty openly... btw the FlexIO and low latency XDR I think are often overlooked... I think they will have a big impact on performance). But even then Xbox programmers can determine how and how much (even if) the L2 cache is used for this special task. Similarly the XeCPU can bypass L1 and L2 cache. So for a general processing core they do seem to be fairly flexible within their design architecture.
But if you define "flexible" as to the type of information the processor can handle then I think XeCPU is much more flexible than the FP/Streaming focused CELL.
Up to this point games have been written, and done well, using "typical" processors. And that is because games do require processing tasks that are NOT FP based. You have load, store, integer, branch, random memory accesses, etc... to take into consideration. These are areas where 3 PPC cores should have an edge and are much more flexible than the SPEs. That XeCPU has more processing power in these areas and with its 115GFLOPs of floating point performance, I would call it more "flexible" or "balanced" design because it can deal with more types of processing tasks at a better overall level.
CELL, on the other hand, is a streaming design aimed primarily at chewing through floating point oriented code. Instead of a good general processor Sony went with a single PPC core and loaded up on Floating Point processing in a streaming design. Since CELL requires the developer to really focus on using the SPEs (i.e. code that is small and floating point friendly) to get the most out of them I would consider that LESS flexible. Asking developers to make their integer based code FP friendly because CELL has 1/3 of the interger performance of the XeCPU is less flexible in my book. Similarly the VMX units are said to be a lot more flexible than the SPEs, but it is a tradeoff of flexibility compared to pure brute power.
But less flexible does NOT mean "not better" or "not as good". Multithreading is forcing developers to face new hurdles they have not had in game design before. Sony's solution is to have dedicated physical units in a stream processing array. MS has gone the more traditional route of going multicore. If flexible is a reference to how multithreaded apps are dealt with they both pose hurdles and will have to wait and see. CELL may very well be better suited, and more flexible, for *multithreaded games*. The question is what will game developers find best/easist to use.
Or we might see that each design excells in different areas and genres.
I do wonder which is the best gamble: ~50% of the FP performance and ~300% of the general processing power or ~200% of the FP performance and ~33% of the general processing power (*Yes, I know these are all peak and multicore CPUs rarely get anywhere near the theoretical jump in performance compared to a single core.) So far games have done pretty well with typical designs, and the XeCPU has ~5x the FP power of a top end PC chip. But in the reverse a streaming processor may be a better way to deal with threads. Personally I think the first couple years (especially launch titles) developers will really struggle, and only as the tools MS and Sony make available improve and developers find new and unique ways to thread their apps will we know if one or the other was a better design.
Until then I expect 3rd party cross platform apps to mainly use the PPC cores and take it slow. 1st parties will lead the charge, and we hopefully will get a glimpse at what these monsters can do soon.
Anyhow, that is my take on the flexibility issue
Per the caches, I would not necessarily disagree. Looking at the caching setup on the XeCPU I can see where it would be more limiting, but that I think it is tradeoffs of a multicore PPC design versus a streaming processor. The flexibility with the SPEs is a necessity of the CELLs streaming design as you need to do a lot of operations on a small amount of data to benefit from a stream processor. So l look at it more as design feature that the multicore PPC does not necessarily need. The XeCPU does seem to be "less flexible" with how it can "lock" for procedural synthesis (compared to how the CELL PPE and SPEs look to use the FlexIO pretty openly... btw the FlexIO and low latency XDR I think are often overlooked... I think they will have a big impact on performance). But even then Xbox programmers can determine how and how much (even if) the L2 cache is used for this special task. Similarly the XeCPU can bypass L1 and L2 cache. So for a general processing core they do seem to be fairly flexible within their design architecture.
But if you define "flexible" as to the type of information the processor can handle then I think XeCPU is much more flexible than the FP/Streaming focused CELL.
Up to this point games have been written, and done well, using "typical" processors. And that is because games do require processing tasks that are NOT FP based. You have load, store, integer, branch, random memory accesses, etc... to take into consideration. These are areas where 3 PPC cores should have an edge and are much more flexible than the SPEs. That XeCPU has more processing power in these areas and with its 115GFLOPs of floating point performance, I would call it more "flexible" or "balanced" design because it can deal with more types of processing tasks at a better overall level.
CELL, on the other hand, is a streaming design aimed primarily at chewing through floating point oriented code. Instead of a good general processor Sony went with a single PPC core and loaded up on Floating Point processing in a streaming design. Since CELL requires the developer to really focus on using the SPEs (i.e. code that is small and floating point friendly) to get the most out of them I would consider that LESS flexible. Asking developers to make their integer based code FP friendly because CELL has 1/3 of the interger performance of the XeCPU is less flexible in my book. Similarly the VMX units are said to be a lot more flexible than the SPEs, but it is a tradeoff of flexibility compared to pure brute power.
But less flexible does NOT mean "not better" or "not as good". Multithreading is forcing developers to face new hurdles they have not had in game design before. Sony's solution is to have dedicated physical units in a stream processing array. MS has gone the more traditional route of going multicore. If flexible is a reference to how multithreaded apps are dealt with they both pose hurdles and will have to wait and see. CELL may very well be better suited, and more flexible, for *multithreaded games*. The question is what will game developers find best/easist to use.
Or we might see that each design excells in different areas and genres.
I do wonder which is the best gamble: ~50% of the FP performance and ~300% of the general processing power or ~200% of the FP performance and ~33% of the general processing power (*Yes, I know these are all peak and multicore CPUs rarely get anywhere near the theoretical jump in performance compared to a single core.) So far games have done pretty well with typical designs, and the XeCPU has ~5x the FP power of a top end PC chip. But in the reverse a streaming processor may be a better way to deal with threads. Personally I think the first couple years (especially launch titles) developers will really struggle, and only as the tools MS and Sony make available improve and developers find new and unique ways to thread their apps will we know if one or the other was a better design.
Until then I expect 3rd party cross platform apps to mainly use the PPC cores and take it slow. 1st parties will lead the charge, and we hopefully will get a glimpse at what these monsters can do soon.
Anyhow, that is my take on the flexibility issue
