|
|
 | | From: | Xenon | | Subject: | Lifting the lid on IBM's Cell chip | | Date: | Thu, 13 Jan 2005 19:35:31 -0600 |
|
|
 | http://www.theregister.co.uk/2005/01/13/ibm_cell_chip/
Lifting the lid on IBM's Cell chip
By Faultline
Published Thursday 13th January 2005 12:25 GMT
A patent issued to IBM, Sony and Toshiba for the Cell microprocessor earned
a brief mention on ZDnet last week, and so Faultline thought it was worth
trying to extract what it could from the detailed technical descriptions.
IBM will shortly be explaining more detail at the US Solid State Circuits
Conference in February. We have always thought that the Cell design was
really a group of processors rather than one single design and this patent
more than confirms that, describing it as a hardware version of the Java
virtual machine.
The underlying aim of IBM appears to be to get this processor to be utterly
ubiquitous across networks. Most client processors are different types of
devices so to execute a program on downloaded data, in a modern highly
network environment like the internet, means having lots of different copies
of application software for each client type. With a Java Virtual Machine a
lot of these problems go away because the JVM executes Java code in the same
way, wherever it is.
However, there are still lots of different types of JVMs to sit on different
hardware clients. This means that there are some security issues with
software sandboxing (segregating all networked content from other software
areas underneath the JVM) and efficiency, because each hardware element has
to work hard to emulate the JVM.
IBM wants to go one step further and have the JVM as a hardware device. It
wants a hardware sandbox in shared memory, and every device to have a unique
global number so that it can be identified and easily located to carry out a
particular task.
As a result every piece of processing that has been carried out on a client
device (cell processor) could be identified and linked back to that
particular processor, which gives a potential hardware layer to security.
Now IBM says that this is such an efficient set up that instead of moving
only data to each processor, data and program function can be shipped at the
same time rather like a Java applet. If the network is genuinely made up of
ubiquitous elements, then the program will always run on any of the devices.
It can also seek out a processing element with the right resources.
Arithmetic Units
The Cell has a single Processing Unit (PU) that schedules workloads and
multiple attached Arithmetic Units, that do the work, all with a direct
memory access controller (DMAC) which looks after access to shared memory
resources.
The PU schedules and orchestrates the processing of data and applications by
the APUs. The APUs perform this processing in parallel. The DMAC controls
accesses by the PU and the APUs to the data and applications stored in
shared Dynamic RAM.
While the overall focus of the architecture is to cope with real-time
multimedia, IBM is clear that it believes that a single common computing
module can be built for clients, servers, PCs, mobile computers, game
machines, PDAs, set top boxes, appliances, digital televisions and more,
with the structure of each just being a variation of how many APUs are under
the Processing Unit's control.
IBM also presents a new programming model which allows for transmitting both
data and applications over a network and to process these among the
network's members.
It presents the idea of a software cell being transmitted which is ready for
the right shaped processor configuration to execute. So the devices are just
naked and the instructions and data get send to them, farmed out by the PU
and processed and the results return to shared memory.
Since all computing resources have the same basic structure and employ the
same instruction set, the particular resource performing this processing can
be located anywhere on the network and dynamically assigned.
Faultline has speculated for the past two years about whether or not the
Cell could ever be big enough for servers and at the same time small enough
for mobile phones. IBM's patent says that not only that the Cell can be used
for both of these, but that it was also designed specifically to be that
way.
begin 666 trpix.gif?&rdm=12747585&dlv=704,20373,230726,112740,458233&kid=112740&chw=9112740-&tcs=&bls3=000000B&bls4=010000230728&uid=1&dmn=.client.comcast.net&scx=1024&scy=768&scc=16&jav=1&sta=,,,1,,,,,,,0,5,0,26443,25819,14659,387,602&iid=230726&bid=458233
K1TE&.#EA`@`"`(#_`,# P ```"'Y! $`````+ `````"``(```("A%$`.P``
`
end
|
|
| | From: | DJ | | Subject: | Re: Lifting the lid on IBM's Cell chip | | Date: | 14 Jan 2005 19:26:17 -0800 |
|
|
| Your getting warmer.
Think Grids.
In this case the cell proceesor device is used in a closed box grid,
processing different pieces of data across the different cell chips.
The data being processed could be one blob or multiple blobs and the
application could be reentrantly loaded across multiple cells or each
cell could be running different parts of the application or even
diffferent applcations. First gen cell processors will scale upto
32x32 grid.
This is the start of a new family of computers.
|
|
| | From: | Ketil Malde | | Subject: | Re: Lifting the lid on IBM's Cell chip | | Date: | Fri, 14 Jan 2005 09:42:48 +0100 |
|
|
| "Xenon" writes:
> The underlying aim of IBM appears to be to get this processor to be utterly
> ubiquitous across networks.
I bet they'd like that.
> Most client processors are different types of devices so to execute
> a program on downloaded data, in a modern highly network environment
> like the internet, means having lots of different copies of
> application software for each client type.
I don't understand what this is supposed to mean. My PC has it's own
copy of GCC for instance. This is a problem? Or if we're talking
network equipment, surely it having a local copy of its software is a
*good* thing?
> With a Java Virtual Machine a lot of these problems go away because
> the JVM executes Java code in the same way, wherever it is.
An example of a processor that executes code in a different way,
depending on location, would be more enlightening, I think. Whatever
this sentence is supposed to convey, I think I missed it.
> However, there are still lots of different types of JVMs to sit on different
> hardware clients. This means that there are some security issues with
> software sandboxing (segregating all networked content from other software
> areas underneath the JVM) and efficiency, because each hardware element has
> to work hard to emulate the JVM.
> IBM wants to go one step further and have the JVM as a hardware device.
Oh, like Sun's (wildly successful) majc? Right, so making it hardware
eliminates security issues and makes it efficient. Great idea!
> It wants a hardware sandbox in shared memory, and every device to
> have a unique global number so that it can be identified and easily
> located to carry out a particular task.
IBM has patented serial numbers? And didn't Intel try this already?
> As a result every piece of processing that has been carried out on a client
> device (cell processor) could be identified and linked back to that
> particular processor, which gives a potential hardware layer to security.
Great for the RIAA, one would presume. I'm not so sure what it would
have any positive implication for security.
> Faultline has speculated for the past two years [...]
I think I have to concur with Maynard's more succint characterisation
-- this didn't make much sense to me, at least. Perhaps it's time for
Faultline to stop speculating, and look for some facts?
-kzm
--
If I haven't seen further, it is by standing in the footprints of giants
|
|
| | From: | John Savard | | Subject: | Re: Lifting the lid on IBM's Cell chip | | Date: | Sat, 15 Jan 2005 17:33:15 GMT |
|
|
| On Fri, 14 Jan 2005 09:42:48 +0100, Ketil Malde
wrote, in part:
>"Xenon" writes:
>> means having lots of different copies of
>> application software for each client type.
>I don't understand what this is supposed to mean. My PC has it's own
>copy of GCC for instance. This is a problem? Or if we're talking
>network equipment, surely it having a local copy of its software is a
>*good* thing?
Well, they mean each client _type_. So they may be thinking about having
to rewrite software to run on different platforms.
>Oh, like Sun's (wildly successful) majc? Right, so making it hardware
>eliminates security issues and makes it efficient. Great idea!
Making it hardware can reduce some security issues. It certainly does
make it efficient. Of course, a nine-bit byte doesn't actually fit into
memories that also contain sixteen-bit characters particularly
efficiently, so the choice of the JVM as the architecture to standardize
upon may be questioned.
If the network software to be used by this chip already existed in Java,
this would make sense. If, however, it tends to exist in other
platforms, then it is from among the architecture of those platforms
that the architecture of the Cell chip should have been chosen.
But if they'd rather not go x86, they could use something sensible, like
the 68020/68881 architecture, or their own PowerPC architecture, or even
their own z/Architecture.
John Savard
http://home.ecn.ab.ca/~jsavard/index.html
|
|
| | From: | Maynard Handley | | Subject: | Re: Lifting the lid on IBM's Cell chip | | Date: | Fri, 14 Jan 2005 02:54:15 GMT |
|
|
| Bullshit, bullshit, bullshit, top to bottom.
Cell is both optimized as as a vector/GPU type engine AND a JVM! Give me
a freaking break.
Maynard
In article ,
"Xenon" wrote:
> http://www.theregister.co.uk/2005/01/13/ibm_cell_chip/
> Lifting the lid on IBM's Cell chip
> By Faultline
> Published Thursday 13th January 2005 12:25 GMT
> A patent issued to IBM, Sony and Toshiba for the Cell microprocessor earned
> a brief mention on ZDnet last week, and so Faultline thought it was worth
> trying to extract what it could from the detailed technical descriptions.
> IBM will shortly be explaining more detail at the US Solid State Circuits
> Conference in February. We have always thought that the Cell design was
> really a group of processors rather than one single design and this patent
> more than confirms that, describing it as a hardware version of the Java
> virtual machine.
>
> The underlying aim of IBM appears to be to get this processor to be utterly
> ubiquitous across networks. Most client processors are different types of
> devices so to execute a program on downloaded data, in a modern highly
> network environment like the internet, means having lots of different copies
> of application software for each client type. With a Java Virtual Machine a
> lot of these problems go away because the JVM executes Java code in the same
> way, wherever it is.
>
>
> However, there are still lots of different types of JVMs to sit on different
> hardware clients. This means that there are some security issues with
> software sandboxing (segregating all networked content from other software
> areas underneath the JVM) and efficiency, because each hardware element has
> to work hard to emulate the JVM.
>
> IBM wants to go one step further and have the JVM as a hardware device. It
> wants a hardware sandbox in shared memory, and every device to have a unique
> global number so that it can be identified and easily located to carry out a
> particular task.
>
> As a result every piece of processing that has been carried out on a client
> device (cell processor) could be identified and linked back to that
> particular processor, which gives a potential hardware layer to security.
>
> Now IBM says that this is such an efficient set up that instead of moving
> only data to each processor, data and program function can be shipped at the
> same time rather like a Java applet. If the network is genuinely made up of
> ubiquitous elements, then the program will always run on any of the devices.
> It can also seek out a processing element with the right resources.
>
> Arithmetic Units
> The Cell has a single Processing Unit (PU) that schedules workloads and
> multiple attached Arithmetic Units, that do the work, all with a direct
> memory access controller (DMAC) which looks after access to shared memory
> resources.
>
> The PU schedules and orchestrates the processing of data and applications by
> the APUs. The APUs perform this processing in parallel. The DMAC controls
> accesses by the PU and the APUs to the data and applications stored in
> shared Dynamic RAM.
>
> While the overall focus of the architecture is to cope with real-time
> multimedia, IBM is clear that it believes that a single common computing
> module can be built for clients, servers, PCs, mobile computers, game
> machines, PDAs, set top boxes, appliances, digital televisions and more,
> with the structure of each just being a variation of how many APUs are under
> the Processing Unit's control.
>
> IBM also presents a new programming model which allows for transmitting both
> data and applications over a network and to process these among the
> network's members.
>
> It presents the idea of a software cell being transmitted which is ready for
> the right shaped processor configuration to execute. So the devices are just
> naked and the instructions and data get send to them, farmed out by the PU
> and processed and the results return to shared memory.
>
> Since all computing resources have the same basic structure and employ the
> same instruction set, the particular resource performing this processing can
> be located anywhere on the network and dynamically assigned.
>
> Faultline has speculated for the past two years about whether or not the
> Cell could ever be big enough for servers and at the same time small enough
> for mobile phones. IBM's patent says that not only that the Cell can be used
> for both of these, but that it was also designed specifically to be that
> way.
>
>
> begin 666
> trpix.gif?&rdm=12747585&dlv=704,20373,230726,112740,458233&kid=112740&chw=9112
> 740-&tcs=&bls3=000000B&bls4=010000230728&uid=1&dmn=.client.comcast.net&scx=102
> 4&scy=768&scc=16&jav=1&sta=,,,1,,,,,,,0,5,0,26443,25819,14659,387,602&iid=2307
> 26&bid=458233
> K1TE&.#EA`@`"`(#_`,# P ```"'Y! $`````+ `````"``(```("A%$`.P``
> `
> end
|
|
| | From: | Del Cecchi | | Subject: | Re: Lifting the lid on IBM's Cell chip | | Date: | Fri, 14 Jan 2005 09:10:21 -0600 |
|
|
| Maynard Handley wrote:
> Bullshit, bullshit, bullshit, top to bottom.
> Cell is both optimized as as a vector/GPU type engine AND a JVM! Give me
> a freaking break.
>
> Maynard
>
>
> In article ,
> "Xenon" wrote:
>
>
>> http://www.theregister.co.uk/2005/01/13/ibm_cell_chip/
>>Lifting the lid on IBM's Cell chip
>>By Faultline
>>Published Thursday 13th January 2005 12:25 GMT
>>A patent issued to IBM, Sony and Toshiba for the Cell microprocessor earned
>>a brief mention on ZDnet last week, and so Faultline thought it was worth
>>trying to extract what it could from the detailed technical descriptions.
>>IBM will shortly be explaining more detail at the US Solid State Circuits
>>Conference in February. We have always thought that the Cell design was
>>really a group of processors rather than one single design and this patent
>>more than confirms that, describing it as a hardware version of the Java
>>virtual machine.
>>
>>The underlying aim of IBM appears to be to get this processor to be utterly
>>ubiquitous across networks. Most client processors are different types of
>>devices so to execute a program on downloaded data, in a modern highly
>>network environment like the internet, means having lots of different copies
>>of application software for each client type. With a Java Virtual Machine a
>>lot of these problems go away because the JVM executes Java code in the same
>>way, wherever it is.
>>
>>
>>However, there are still lots of different types of JVMs to sit on different
>>hardware clients. This means that there are some security issues with
>>software sandboxing (segregating all networked content from other software
>>areas underneath the JVM) and efficiency, because each hardware element has
>>to work hard to emulate the JVM.
>>
>>IBM wants to go one step further and have the JVM as a hardware device. It
>>wants a hardware sandbox in shared memory, and every device to have a unique
>>global number so that it can be identified and easily located to carry out a
>>particular task.
>>
>>As a result every piece of processing that has been carried out on a client
>>device (cell processor) could be identified and linked back to that
>>particular processor, which gives a potential hardware layer to security.
>>
>>Now IBM says that this is such an efficient set up that instead of moving
>>only data to each processor, data and program function can be shipped at the
>>same time rather like a Java applet. If the network is genuinely made up of
>>ubiquitous elements, then the program will always run on any of the devices.
>>It can also seek out a processing element with the right resources.
>>
>>Arithmetic Units
>>The Cell has a single Processing Unit (PU) that schedules workloads and
>>multiple attached Arithmetic Units, that do the work, all with a direct
>>memory access controller (DMAC) which looks after access to shared memory
>>resources.
>>
>>The PU schedules and orchestrates the processing of data and applications by
>>the APUs. The APUs perform this processing in parallel. The DMAC controls
>>accesses by the PU and the APUs to the data and applications stored in
>>shared Dynamic RAM.
>>
>>While the overall focus of the architecture is to cope with real-time
>>multimedia, IBM is clear that it believes that a single common computing
>>module can be built for clients, servers, PCs, mobile computers, game
>>machines, PDAs, set top boxes, appliances, digital televisions and more,
>>with the structure of each just being a variation of how many APUs are under
>>the Processing Unit's control.
>>
>>IBM also presents a new programming model which allows for transmitting both
>>data and applications over a network and to process these among the
>>network's members.
>>
>>It presents the idea of a software cell being transmitted which is ready for
>>the right shaped processor configuration to execute. So the devices are just
>>naked and the instructions and data get send to them, farmed out by the PU
>>and processed and the results return to shared memory.
>>
>>Since all computing resources have the same basic structure and employ the
>>same instruction set, the particular resource performing this processing can
>>be located anywhere on the network and dynamically assigned.
>>
>>Faultline has speculated for the past two years about whether or not the
>>Cell could ever be big enough for servers and at the same time small enough
>>for mobile phones. IBM's patent says that not only that the Cell can be used
>>for both of these, but that it was also designed specifically to be that
>>way.
>>
Some people don't understand the patent process. When writing a patent,
one doesn't normally describe what one is actually developing, one
describes the idea at as basic and broad a level as possible, and
includes all the variations or options that one can think of. So trying
to figure out what someone is building by reading patents in any
specific way is often an exercise in futility.
That is not to say that I have any knowledge of the "cell" chip because
I don't. But they would be foolish not to claim all the alternatives
they could think of.
Be a lot easier just to go to San Francisco on Feb 6-10 and pay your 945
dollar registration for ISSCC. Get a nice room at the Marriot and
relax. Have geek fun and learn something.
del cecchi
del cecchi
|
|
| | From: | Robert Myers | | Subject: | Re: Lifting the lid on IBM's Cell chip | | Date: | Fri, 14 Jan 2005 22:58:47 -0500 |
|
|
| On Fri, 14 Jan 2005 09:10:21 -0600, Del Cecchi
wrote:
>
>That is not to say that I have any knowledge of the "cell" chip because
>I don't. But they would be foolish not to claim all the alternatives
>they could think of.
>
>Be a lot easier just to go to San Francisco on Feb 6-10 and pay your 945
>dollar registration for ISSCC. Get a nice room at the Marriot and
>relax. Have geek fun and learn something.
>
Be a neat conference for learning weenie details, but it probably
won't slide Cell into where it fits among STREAM, GPU's, and IBM's own
TRIPS chip. What's the same and what's different will be the
interesting things to know.
I *know* how much you hate general purpose computing on GPU's, but
I'll be real surprised to learn that Cell is anything much different.
As always, I'm ready to be surprised, and the patent summary suggests
that there might be some interesting twists, at least.
With or without Cell, the days of trips back and forth between
registers and cache are numbered. Thread elsewhere about no new
ISA's. With so much power available from stream processors and no
effective way to move data around the die as feature sizes shrink, the
better question might be whether people will people be using the old
ISA's in ten years. Everything will be processing packets on the fly.
RM
|
|
| | From: | del cecchi | | Subject: | Re: Lifting the lid on IBM's Cell chip | | Date: | Sat, 15 Jan 2005 19:52:24 -0600 |
|
|
|
"Robert Myers" wrote in message
news:nd4hu05dsmp4grb1q96otsui993h60gnii@4ax.com...
> On Fri, 14 Jan 2005 09:10:21 -0600, Del Cecchi
> wrote:
>
>
> >
> >That is not to say that I have any knowledge of the "cell" chip
because
> >I don't. But they would be foolish not to claim all the alternatives
> >they could think of.
> >
> >Be a lot easier just to go to San Francisco on Feb 6-10 and pay your
945
> >dollar registration for ISSCC. Get a nice room at the Marriot and
> >relax. Have geek fun and learn something.
> >
>
> Be a neat conference for learning weenie details, but it probably
> won't slide Cell into where it fits among STREAM, GPU's, and IBM's own
> TRIPS chip. What's the same and what's different will be the
> interesting things to know.
>
> I *know* how much you hate general purpose computing on GPU's, but
> I'll be real surprised to learn that Cell is anything much different.
> As always, I'm ready to be surprised, and the patent summary suggests
> that there might be some interesting twists, at least.
Me? I don't hate anything. Well, there are a few executives from years
back.... :-)
But the GPU for general purpose computing? not me. It does puzzle me
as to what features a GPU would have that would be so advantegous for
general purpose computing but that general purpose cpus don't have.
It's not like those features are secret. So I could be classified as
sceptical.
And what is IBM's TRIPS chip? That doesn't ring any bells.
>
> With or without Cell, the days of trips back and forth between
> registers and cache are numbered. Thread elsewhere about no new
> ISA's. With so much power available from stream processors and no
> effective way to move data around the die as feature sizes shrink, the
> better question might be whether people will people be using the old
> ISA's in ten years. Everything will be processing packets on the fly.
>
> RM
I bet they will still be running Cobol programs written for 360 systems.
Ten years isn't very long.
del cecchi
|
|
| | From: | Robert Myers | | Subject: | Re: Lifting the lid on IBM's Cell chip | | Date: | Sat, 15 Jan 2005 21:32:42 -0500 |
|
|
| On Sat, 15 Jan 2005 19:52:24 -0600, "del cecchi"
wrote:
>
>"Robert Myers" wrote in message
>news:nd4hu05dsmp4grb1q96otsui993h60gnii@4ax.com...
>>
>> Be a neat conference for learning weenie details, but it probably
>> won't slide Cell into where it fits among STREAM, GPU's, and IBM's own
>> TRIPS chip. What's the same and what's different will be the
>> interesting things to know.
>>
>> I *know* how much you hate general purpose computing on GPU's, but
>> I'll be real surprised to learn that Cell is anything much different.
>> As always, I'm ready to be surprised, and the patent summary suggests
>> that there might be some interesting twists, at least.
>
>Me? I don't hate anything. Well, there are a few executives from years
>back.... :-)
>But the GPU for general purpose computing? not me. It does puzzle me
>as to what features a GPU would have that would be so advantegous for
>general purpose computing but that general purpose cpus don't have.
>It's not like those features are secret. So I could be classified as
>sceptical.
>
I withdraw the characterization. It's another poster who *hates*
general purpose computing on GPU's. You only made a slightly sour
joke about supercomputing on playstations. ;-).
While I've been whining about using yesterday's embedded processors to
build tomorrow's supercomputers (we're just not going to agree about
Blue Gene, but I am, as always, happy to repeat my admiration for the
engineering achievement in terms of power and computational density),
the future has been happening:
http://www.gpgpu.org/
http://www.computer.org/computer/homepage/1003/entertainment/
>And what is IBM's TRIPS chip? That doesn't ring any bells.
>
http://www.newsfactor.com/perl/story/22191.html
Joint IBM/UT Austin, DARPA-funded. I don't have recent information.
Somebody here does, I'm sure.
By scaling arguments due to Bill Dally that at least I have posted
about, you should be able to achieve computational densities with
stream processors that you can't achieve with conventional
microprocessors because the costs of moving instructions and data
around dominate the energy costs as the features shrink.
With a conventional ISA, you are constantly getting and putting to
registers from and to cache. With a stream processor, the data are
always on their way to the next operation, rather than on their way
back to a holding pen. Those back and forth moves are merely a
logical detail from the point of view of coding. They are no longer
insignificant from the point of view of power consumption and they
will dominate over execution units with smaller feature size.
Don't have to dream about it. People are writing CFD for COTS
graphics cards. Not particularly good news for me. I don't know
shader language, either, but it's exciting. Another issue I've been
whining about has about has also been addressed. Direct X 9 and newer
GPU's support 128-bit floating point.
I'm assuming that Cell is just another version of this class of ideas
because it's the only way I can imagine to achieve the comptutational
densities people have been throwing around. The really interesting
thing will be to see what's unique about Cell.
>>
>> With or without Cell, the days of trips back and forth between
>> registers and cache are numbered. Thread elsewhere about no new
>> ISA's. With so much power available from stream processors and no
>> effective way to move data around the die as feature sizes shrink, the
>> better question might be whether people will people be using the old
>> ISA's in ten years. Everything will be processing packets on the fly.
>>
>
>I bet they will still be running Cobol programs written for 360 systems.
>
>Ten years isn't very long.
>
They will be running Cobol programs for 360 systems after I'm off the
scene, I'm sure. Those programs will probably be running on
conventional microprocessors for a while. We'll know the era of
register files is finally ending when packets of 360 instructions are
being translated on the fly as a stream. It will happen.
RM
|
|
|
