Kentsfield as an alternative to Cell in PS3

Could you expound on that please? Could it not run simple programs deligated similar to spe's but obviously smaller/less complex?

 

The current Polaris implementation seems to rely on memory that is directly bonded to the processor die. I don't think Intel has given much detail on what exactly the memory is or its capacity, so it's hard to say if each mini-core can be treated like a very simple SPE or if there are other wrinkles to the design.

 

From front page of Beyond3D...

 

Thanks Patsu, but believe it or not the front page article is actually what sparked the question in the first place. It didn't give the in-depth description I was looking for here in seeing whether the tech might be of some use in a future console.

 

You could probably use it as a coprocessor for example as a PPU to handle really complicated physics since it's capable of 1 TFLOPS (single precision) at 3GHz. You probably could divide it up into 4 smaller dies each having 20 cores mounted in a SiP to improve yields and lower costs. Intel has designed each core to be tileable so you just slap more cores on when you want more processing capability. It doesnt' even seem like the cores need to be clustered into groups of 8 etc.

 

Cell slaughters the Kentsfield in Floating Point but the Kentsfield slaughters Cell in Integer and general purpose.

 

No, the Cell has integer performance to match its floating point performance... and in terms of 'general purpose,' what does that even mean? If we're talking about x86 and OOE execution, then yes. But any 'general purpose' task that can be executed on any other architecture can be optimized to run on Cell as well. Optimization, and thus effort, is the key.

 

SIMD operations can operate on int values.
Scalar int operations would favor Kentsfield per-core, and arguably would favor the x86 chip overall.

 

Assuming you can write very concurrent integer code. For single threaded code its an easy Kentsfield victory.

 

See, here's the problem - two years after the fact, there are still people living in the shadow of Major Nelson's post-E3 article of '05. Toss that sh*t out.

Like I said, when people refer to 'general purpose' code, they are talking basically about unoptimized code created to perform a specific task; the burden is placed on the hardware more or less to run effectively. Kentsfield, as most x86 architectures, is obviously well suited for this - its entire design paradigm is centered around this. Out-of-order execution is the key element, as well as support for a massive legacy-code base. And in this, obviously obviously Kentsfield lays waste to Cell.

Ok.

Now... when people use 'general purpose' loosely though, as was done by Pigman, they do so unsure of what they're saying, but with vague notions of AI performance, gameplay elements, etc etc... and these are two different things. That code is only general purpose insomuch as normally in the PC space it is also unoptimized, relies on heavy-branching, and so on and so on. So when you hear things like "Cell is bad on general purpose code...," what you're hearing is the distilled thoughts boiled down essentially with regard to Cell's performance on current code (and coding practices). But yes, with the time and effort taken to optimize, Cell can run these things extremely well. *That* conversation, time/reward for doing such optimization, is a different thread topic in and of itself. But the idea that 'general purpose' is some nebulous concept that can't have qualities associated with it save what gets regurgitated from some wildly over-simplified (and largely incorrect) article of two years ago has got to end. It's sad, because the average layperson actually knows less about processors for Nelson's legacy rather than more, with the ironic twist than in their own minds it's just the opposite.

 

Uh, well it's more complicated than that... but essentially yes... essentially.

That doesn't make Cell a 'better' processor though - it just makes it a different processor. See, that's the whole thing; consider both Kentsfield and Cell to be 'miracle' chips - it's simply that what those miracles are, are different. With Cell, if you write the proper code, your app is going to fly like the wind. The 'miracle' here is potential; the cost is rethinking the way you write code, becoming less reliant on compilers to get you there, and basically more time and money spent on the software dev side (this is not an absolute truth, but a relative one).

On the other hand, the 'miracle' of Kentsfield - and all of the OOE x86 chips with which it competes - is that they can take the most poorly written, unoptimized, and terrible piece of legacy x86 code from 1990... run it, and in fact run it much faster than it ran on the processors contemporary to when that code was originally written. The benefit is cheap(er), and quicker, software development. As these architectures go increasingly multi-core, there will be increased crossover between them and processors like Cell in terms of dev challenge, but I think this helps paint a picture for you of why in the present day even though a world built on Cell might ultimately be faster, it's just simply a world we can't afford to move to on the desktop on a macro level from an infrastructure, ecosystem, or economic standpoint. I think whatever course the desktop takes, it will remain largely the realm of x86 for quite some time to come; every year that passes, legacy support only becomes more crucial than the last.

I'm a fan of Cell though, and I think there are definitely places for it and architectures like it going forward; not everywhere is the desktop, and there are lots of industries willing to put the time in to optimize if it means a tangible improvement in execution.

 

General purpose code sounds like any software product that has a development cost structure and target market that does not permit pervasive low-level optimization to a single platform.

Perhaps it is code that was made without the assumption that a problem can be easily subdivided and run as a streaming or batched application, where the data could not be assumed to be amenable to SIMD execution, or the dynamic behavior proves extremely difficult to profile at compile time.

Perhaps it is software for a problem that can be run as such, but that the required overhead makes it undesirable when compared to more general architectures.

 

Terascale

 

To me the term "general purpose code" does not sound like unoptimized code. It's more like the high level language code you can directly compile for multi-platform use, e.g. a C++ FFT routine which only uses standard floating point operation.

 

Agreed.

 

Which is unoptimized code! Those algorithms will perform differently well on different architectures. An architecture that runs them well is considered to be good at 'general purpose code'. The actual tasks that 'general purpose code' perform are not 'general purpose tasks' : 'general purpose tasks' don't exist. Thus a chip that performs poorly on 'general purpose code' may not be bad at the task that code is doing; it could just be needing a different, non-generalised implementation. That doesn't mean to say that any processor can perform well at any task, though. Some processors just aren't well designed for some tasks no matter what the implementation.