Interview: Nick Baker on the XBox 360 Architecture

That was definitely a possibility. Cell has 8 cores. Lose the LS and you could fit 16 cores. Memory management would kill you though. And if they went with 8 cores, may as well go with Cell!

With x86 though the instruction decode stage is large because, presumably, you'd want to convert into a RISC microcode. Also, x86 on its own has a horrid FP implementation! As for the LS, that is the beauty of the Cell architecture; you could drop them and use L1 caching etc., but with MS wanting OoOE execution if they went with x86 it would be a prohibitively large matching store for the Re-Order Buffers. You simply couldn't fit it on a chip, not even of Cell's size.
 
Talking about Intel, they have just released an update of their compiler with built-in support for multi-core CPUs (link):
The C++ compiler comes with a set of thread building blocks aimed at shielding programmers from the still-evolving details of Intel's multi-core processors. The building blocks automate some of the low-level decisions about how to make particular tasks parallel.

"We encourage people to use these abstractions," said Reinders. "People need to express parallelism at a high level so they don't have to go back and readjust their assumptions when the system changes," he said.

"For instance the size of the processor cores may not be symmetric in the future. And you don't always want to divide tasks up evenly across processors anyway," he added.
I found this part interesting as well:
Another top priority for the Intel group is to develop debugging tools for its multicore processors.

"This is where we are investing most of our new resources," said Reinders. "The debug tools for multicore CPUs are inadequate today, and if we don't improve them people will just decide programming for multicore processors is too difficult. There is a huge amount we ca do in this area in the next 24 months," he said.
Probably the same kind of stuff as IBM et al is working on.

Looks like Intel is well on the road heading toward asymmetric CPUs, which is further clarified here:
Speaking at the Design Automation Conference here on Thursday (June 7), Borkar, director of Intel's Microprocessor Technology Lab, argued, "You cannot simply follow the path of multicore evolution, integrating multiple complex cores on a die."

While Borkar's proposal for integrating lots of smaller cores would mean lower performance than a large, complex core, total compute throughput would be much higher.

He argued that a 1-billion logic transistor, rather than integrating ten large 100-million transistor cores, would allow designers to integrate 100 medium, 10-million transistor cores or even 1,000 smaller cores.

"If you apply Pollack's Rule inversely, performance of a smaller core reduces as square root of the size, but power reduction is linear, resulting in smaller performance degradation with much larger power reduction," said Borkar.
There we have further evidence that big fat cores will soon belong to the past.
 
Last edited by a moderator:
With x86 though the instruction decode stage is large because, presumably, you'd want to convert into a RISC microcode.
They weren't talking about full cores though, but vector processing cores. The original idea was one mainstream x86 core, a few smaller general purpose cores, and lots of tiny coprocessors. Or something like that. It did sound very Cell-like in concept to me. Maybe their original idea was heavily influenced by Sony's plans, and when they reconsidered they went with a different approach?
 
Talking about Intel, they have just released an update of their compiler with built-in support for multi-core CPUs (link):

I found this part interesting as well:

Probably the same kind of stuff as IBM et al is working on.

Looks like Intel is well on the road heading toward asymmetric CPUs, which is further clarified here:

There we have further evidence that big fat cores will soon belong to the past.

Just long as single threaded performance doesn't go backwards then thats fine. Unless of course all software becomes highly multithreaded. Im not sure if thats even possible though so I wouldn't mind 2-4 large cores for my single threaded needs (across multiple simultaneous apps) with lots of smaller cores for my performance needs in apps that can benefit from multithreading. Basically a Cell design but with decent single threaded performance.
 
Just long as single threaded performance doesn't go backwards then thats fine. Unless of course all software becomes highly multithreaded.
Which i'm sure it will as both software AND hardware diverge further and further away from a unified sequential execution model to handle a variety of separate (and some mutually exclusive) tasks, and to much more parrallel, focused code demonstrating separation of concerns down to the thread level (and in some cases, sub-thread level)...

J Im not sure if thats even possible though so I wouldn't mind 2-4 large cores for my single threaded needs (across multiple simultaneous apps) with lots of smaller cores for my performance needs in apps that can benefit from multithreading. Basically a Cell design but with decent single threaded performance.
To be honest I doubt hardware parrallelism will matter with regards to single-threaded application development.. What will matter most will be compiler efficiency with respect to adaquately organising your sequantial code to run "optimally" on non-sequential hardware (since thats where all the hardware seems to be going.. Unless you develop for cell phones and even then i'd imagine increased parrallelism in the hardware to ramp up over the next couple of years since there are many areas where the performance could benefit from it..)
I doubt any of the hardware manufacturers will pay much attention to maintaining top performance for ST since the only real benefit as it stands now is productivity (easier to understand, hence less error prone).. Once better tools, more parrallel-execution-centric compilers, debuggers etc are commonplace, nobody will care about how fast your game will run on one core because you'd never want to use only one..
 
Back
Top