I enjoy a good graphics argument
It's just the frequent bullshit posts contained in them thats bad

That L2 cache is not as important as in other architectures, as each SPE can rely on DMA and SPEs communicate between them through a bus. It means having to manage memory access at a very low level, but it can be highly optimized. Some extra effort is also needed on the 360 to avoid L1 cache contention troubles (the two threads of each of the 3 cores share the L1 cache), so in general memory management has been a critical issue in this generation of consoles.

As to the bolded, the trend seems to be the opposite.

In-order processors are simpler and cheaper, and they allow for a greater number of concurrent cores per die. It's not an accident that such a design choice was made by IBM, and the same was done by Intel with Larrabee sharing a lot of design ideas with Cell - I think that's where the GPU/CPU hybrids will go next.

OMG this article is old, infact its a good 3 years old, and in 3 years time allot can and has changed, so I wouldn't say that it's a 100% factual...

yup..as a good example the cell "TRE" or "Terrain Rendering Engine" that was shown back in 2005 on the cell

was able to get 30 fps without even going through a GPU just off the Cell alone.

another example:

IN CT reconstruction:

Fast GPU-Based CT Reconstruction using the Common Unified Device Architecture (CUDA) Scherl, H.   Keck, B.   Kowarschik, M.   Hornegger, J.   Friedrich-Alexander- Univ. Erlangen-Nurnberg, Erlangen; This paper appears in: Nuclear Science Symposium Conference Record, 2007. NSS '07. IEEE Publication Date: Oct. 26 2007-Nov. 3 2007 Volume: 6,  On page(s): 4464-4466 Location: Honolulu, HI, ISSN: 1082-3654 ISBN: 978-1-4244-0922-8 INSPEC Accession Number: 9892023 Digital Object Identifier: 10.1109/NSSMIC.2007.4437102 Current Version Published: 2008-01-22

Abstract The Common Unified Device Architecture (CUDA) is a fundamentally new programming approach making use of the of the most current Graphics Processing Units (CPUs) from NVIDIA. The programming interface allows to implement an algorithm using standard C language and a few extensions without any knowledge about graphics programming using OpenGL, DirectX, and shading languages. We apply this revolutionary new technology to the FDK method, which solves the three-dimensional reconstruction task in cone-beam CT. The computational complexity of this algorithm prohibits its use for many medical applications without hardware acceleration. Today's CPUs with their high level of parallelism are cost-efficient processors for performing the FDK reconstruction according to medical requirements. In this paper, we present an innovative implementation of the most time-consuming parts of the FDK algorithm: filtering and back-projection. We also explain the required transformations to parallelize the algorithm for the CUDA architecture. Our implementation approach further allows to do an on-the-fly- reconstruction, which means that the reconstruction is completed right after the end of data acquisition. This enables us to present the reconstructed volume to the physician in real-time, immediately after the last projection image has been acquired by the scanning device. Finally, we compare our results to our highly optimized FDK implementation on the Cell Broadband Engine Architecture (CBEA), both with respect to reconstruction speed and implementation effort. http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?tp=&arnumber=4437102&isnumber=4437000 IE: unified shader's done on the Cell processor...

if i'd buy a console just for graphics than i rather stare at the wall ...

oh lovely wall, good texture it looks like REAL! seriously look at that detail.

IT doesnt matter when an article was written, the componenets of a machine dont change. That IBM article you posted is what the tech specialist used and has as a source on the final page of his disection. Yes they are tests. But tests are done in a controlled environment. Notice how on IBM's very own graphs they show they can actual only get 75% of the theoretical power when using all SPE's at once?

That IBM article completely backs up this tech persons article. Theoretical PS3 can do 218 GFLOPS with the cell. Actual game environment will be closer to 70 GFLOPS in the best games of this gen. For some reason Cell loses alot of peak ower when all SPE's are being used. 360's Xenon will likely see around 60 GFLOPS peak for actual games. But again Cell can help out The weak RSX where it needs to. And Xenos on 360 has the ability to help out Xenon CPU. Because the Xenos is very much more advanced than RSX. It's catch 20/20.

The article is very factual. Yes developers will always find ways around problems of hardware, and in terms of console hardware these 2 consoles are a big step up from the previous generation. But the actual CPU's inside 360 and PS3 aren't actual capable of more than Athlon 3200+ for instance. Becasue In Order Execution CPU's have a very limited way of being used. And adding multithreading makes that even harder. If cell and Xenon were Out of Order CPU's they would be considerably more powerful and faster at what they could do, but they wouls alos lkely cost you to sell your mum to buy the console.

The only part that can change in from the article is the OS usage. How much ram and how much processing time. But thats it. The rest will never change, but developers will learn ways like they did last gen to overcome any hiccups. And g=create great games like Killzone 2, or Forza 3. It's the nature of the beast.

The main points I got from the article is that in no way Is PS3 or 360 supercomputers. Also PS2 had a better CPU than Xbox 1, yet Xbox 1 provided greater graphics. How advanced the 360 GPU actually is. And how the gap this gen between the 2 are closer than the gap between PS2 and Xbox 1.

You have to remember that the hard facts about machines dont change. The specs dont change, how out of order CPUs work dont change, how memory works doesn't change and the article even talks about how developers can use the SPE's to their advantage or not.

Lets not discredit factual information because it hurts our fanboyism. I have no problem in admitting I was wrong that PS3 Cell wasn't that powerful. But like the article says using SPE's for things like cloth motion etc means the cell can display more on screen than the xenon.

But as he points out on a whole the machines are so much closer than last gen, becasue RSX is helped by Cell and Xenon is helped by Xenos. It's like M$ really went for awesome graphics chip and Sony went for awesome CPU. And in the thick of it both machines can use the stronger chip to help out their weaker chip to overcome an shortcomings. It's funny really. But thats life.

It's also worth noting that multithreaded engines like UE3 are nowhere near fully optimized multithreading code. this can take even another 3 or 4 years to perfect.

if you did buy a console just for graphic's..that wall just might eat you if you stare at it wrong...

once again i respect this guy's Opinion based on what he has read about the Cell but i have to disagree with his take on how that technology is used , based on his experience of the Cell. for instance you say that the IBM test's are in controlled enviroment...but on the same token back in 2005 the API's were not as well developed for the Cell as they are now, the very fact that even back in 2005 they were getting 30 fps TRE on the same CPU that is in the PS3 and this was shown working at the trade show points to the fact that his claim's are based on his OPINION on what data he had on hand. which he did not have all the data of each system. he just had what he had, and he made his Opinion known on his blog based on that data.

I do not fault him for it other than its way outdated.

I have no problem in you posting what you did because it give's you and idea what this person's experience with what he has about both platform's,

Me i do not tend to only look at just one article based on 2005, or 2006 to say this is fact's if the person has not done any test's themselves., does it mean he's 100% wrong or right depends on who you ask. me i see some of the thing's he did get right, on the ps3 but his take on how to impliment the development process is wrong, which would give much more results than what he has stated. Like i said i am not knocking his take due to what info he only had on hand at the time.

i am not knocking it being posted i am just knocking on it's relevance today.

EXAMPLE:

IBM has done test's on both the xbox360 processor and the Cell processor both are very powerful processor's but even IBM which created both processor's has stated the Cell canreach close to its maximum Flops compared to the xbox360's. this does not mean much anyway because it's upto the developer and his experience with the hardware.

did you ever think the Cell processor can do unified shader''s but it can.

I won't comment on the remainder of your post, because I think I made my point yet.

But the bolded part is factually wrong. In-order and out-of-order CPUs are not qualitatively different.

Out-of-order architectures are simply more efficient at instruction-per-clock cycle because they internally reorder the instructions they receive to more efficiently fill their pipelines. But the way you can use them is exactly the same: they can process the same instruction sets etc. For example the Atom CPU line designed for netbooks by Intel is in-order, but you can throw your usual x86 windows code and it will process it happily. At the same clock it will be less powerful than an out-of-order P3, but it's not limited a priori, it simply yields a different computational power per megahertz ratio.

In particular, when you go massively parallel you choose a different investment in circuitry complexity for computation power, prefering adding cores instead of the instruction-reordering circuitry. Having 3 or 7 cores is only the start: Larrabee GPUs will probably start with 32-64 cores.

Look at it this way: out-of-order processing and hyperthreading are actually vestiges of the era when you had a single core, so you went for internal parallelization of microops as much as you could and tried to optimize that. The nature of the x86 instruction set limited this to 3 or 4 internal pipelines and 2 threads, and by what I see with 360 and PS3 the PowerPC instruction set doesn't offer better chances.

As we move that parallelism out to the multi-core, NUMA architectures we can scale this up to tens and hundreds of concurrent operations. It makes sense for the sake of scalability and modularity if the internal complexity of each module is kept to a minimum. The price you pay, of course, is the external complexity of software.

Once again, let me bring up Larrabee as an example: when that kind of CP/GPU becomes the norm there won't be any reason to upgrade the hardware only because new features of DirectX and OpenGL must be implemented and optimized in hardware. It will only take an updated driver to digest those new function calls on the universal CP/GPU: the complexity moves from hardware implementation to software.

So, do we have a Cliffnotes version of the article yet?