| Author |
Message |
Maynard Handley
Guest
|
 Posted:
Sat Jan 22, 2005 6:53 am Post subject:
Re: Cell Architecture Explained (MASSIVE AMOUNT OF INFO) |
|
|
In article <QvadnatFwfzw6W3cRVn-ow@comcast.com>,
"Xenon" <xenonxbox2@xboxnext.com> wrote:
| Quote: | The lack of cache and virtual memory systems means the APUs operate in a
different way from conventional CPUs. This will likely make them harder to
^^^^^
program but they have been designed this way to reduce complexity and
increase performance.
|
You don't say.
Programming Itanic was a picnic compared to programming this thing; at
least Itanic used a traditional computer architecture.
And yet Intel/HP, with all the money in the world, couldn't make it fly.
Please tell us why IBM/Sony/Toshiba can do what Intel/HP could not.
(Note, I am not denying that Cell may make a fine Playstation chip.
I AM denying that it will make a fine workstation chip, will take over
the computing world, make all other CPUs obsolete, blah blah blah.)
| Quote: | This may sound like an inflexible system which will be complex to program
and it most likely is but this system will deliver data to the APU registers
|
So in return for giving up cache, your code has to manually move data
to/from memory. That'll be easy for the compiler to figure out.
| Quote: | at a phenomenal rate. If 2 registers can be moved per cycle to or from the
local memory it will in it's first incarnation deliver 147 Gigabytes per
second. That's for a single APU, the aggregate bandwidth for all local
|
2 AltiVec registers per cycle can be moved to/from cache on a PPC970
today. That's nice, but doesn't change the fact that the problem is
getting stuff to from MAIN MEMORY not to/from LOCAL MEMORY/CACHE.
| Quote: | While there is not coherency mechanism in the APUs a mechanism does exist.
To prevent problems occurring when 2 APUs use the same memory, a mechanism
is used which involves some extra data stored in the RAM and an extra "busy"
bit in the local storage.
|
There's (much much, so much) more blather and ranting about how how
fantastic Cell is and how it will solve any problem you can possibly
imagine, but for those of us in the reality-based community, I think the
points I have extracted above are the highlights.
Bottom line is that this thing doesn't resemble any traditional CPU and
is therefore a godawful match to existing languages, compilers and
algorithms. Unless IBM/Sony/Toshiba have, in some other pocket, and kept
an extremely good secret that solves problems many people have been
working on for more than twenty years, you'll be programming this thing
with an assembly language mindset, even if you are nominally using a
high-level language --- like you program AltiVec today. Only it'll be so
much more fun because not only will you be worrying about alignment and
algorithm issues, you'll be trying to juggle fitting your instructions
and data into local memory (we weren't given a size for this but if it
is to run at L1 cache speeds, it can't be wildly far off from say 64K to
512K bytes); none of that getting the cache to just hide the problem for
you if you might want to load from an infrequent used table, handle a
rare exception condition or whatever; it'll be manual segment swapping
all over again. Not to mention the other glorious aspects. You'll be
using some bizarro method to handle coherency. You'll have the engine
that drives your code and handles exceptions and such running on a
different processor from where the compute intensive code lives.
And all this from IBM/Sony/Toshiba, three companies traditionally known
for their openness and willingness to share with the public. I imagine
Intel, AMD and Microsoft are quaking in their boots.
Maynard |
|
| Back to top |
|
 |
del cecchi
Guest
|
| Posted:
Sat Jan 22, 2005 7:09 am Post subject:
Re: Cell Architecture Explained (MASSIVE AMOUNT OF INFO) |
|
|
(followups trimmed, )
"Maynard Handley" <name99@name99.org> wrote in message
news:name99-42B264.17530821012005@localhost...
| Quote: |
snip
You don't say.
Programming Itanic was a picnic compared to programming this thing; at
least Itanic used a traditional computer architecture.
And yet Intel/HP, with all the money in the world, couldn't make it
fly.
Please tell us why IBM/Sony/Toshiba can do what Intel/HP could not.
(Note, I am not denying that Cell may make a fine Playstation chip.
I AM denying that it will make a fine workstation chip, will take over
the computing world, make all other CPUs obsolete, blah blah blah.)
snip |
| Quote: | And all this from IBM/Sony/Toshiba, three companies traditionally
known
for their openness and willingness to share with the public. I imagine
Intel, AMD and Microsoft are quaking in their boots.
Maynard
|
A couple of points
Trying to figure out anything like this by reading patents is totally
futile.
Wasn't the "emotion engine" considered a little weird also?
IBM/Sony open and willing to share with the public? Not the IBM and
Sony I know. Not while the product is in development. I guess we will
hear what is really on the chip, or at least one chip at ISSCC in a
couple weeks. And I don't recall IBM saying Cell would take over the
world etc etc. But maybe I missed it.
del cecchi (I know no details about the chip or strategy) |
|
| Back to top |
|
|
CEO Gargantua
Guest
|
| Posted:
Sat Jan 22, 2005 7:55 am Post subject:
Re: Cell Architecture Explained (MASSIVE AMOUNT OF INFO) |
|
|
Maynard Handley wrote:
| Quote: | (Note, I am not denying that Cell may make a fine Playstation chip.
I AM denying that it will make a fine workstation chip, will take over
the computing world, make all other CPUs obsolete, blah blah blah.)
|
Moore's Law is dead, and it's taking Wintel down with it.
All this /cell/ and other stuff is way to make something out of nothing
-- they can't fit any more transitors on the silicon. It's over ok.
All I see is decreasing profit margins for chip makers.
--
incognito...updated almost daily
http://kentpsychedelic.blogspot.com
Texeme Textcasting Technology
http://texeme.com |
|
| Back to top |
|
|
Maynard Handley
Guest
|
| Posted:
Sat Jan 22, 2005 7:56 am Post subject:
Re: Cell Architecture Explained (MASSIVE AMOUNT OF INFO) |
|
|
In article <35dsgbF4l8k28U1@individual.net>,
"del cecchi" <dcecchi.nojunk@att.net> wrote:
| Quote: | (followups trimmed, )
"Maynard Handley" <name99@name99.org> wrote in message
news:name99-42B264.17530821012005@localhost...
snip
You don't say.
Programming Itanic was a picnic compared to programming this thing; at
least Itanic used a traditional computer architecture.
And yet Intel/HP, with all the money in the world, couldn't make it
fly.
Please tell us why IBM/Sony/Toshiba can do what Intel/HP could not.
(Note, I am not denying that Cell may make a fine Playstation chip.
I AM denying that it will make a fine workstation chip, will take over
the computing world, make all other CPUs obsolete, blah blah blah.)
snip
And all this from IBM/Sony/Toshiba, three companies traditionally
known
for their openness and willingness to share with the public. I imagine
Intel, AMD and Microsoft are quaking in their boots.
Maynard
A couple of points
Trying to figure out anything like this by reading patents is totally
futile.
Wasn't the "emotion engine" considered a little weird also?
|
And with good reason. Tell me, today, how well standard C code doing
something like XML parsing runs on an emotion engine.
| Quote: | IBM/Sony open and willing to share with the public? Not the IBM and
Sony I know. Not while the product is in development. I guess we will
hear what is really on the chip, or at least one chip at ISSCC in a
couple weeks. And I don't recall IBM saying Cell would take over the
world etc etc. But maybe I missed it.
|
You did indeed miss it. We have had, apart from Xenon's wild visions,
officials from Sony claiming that Cell will make a magnificent
workstation chip, and officials from IBM claiming that it's a fine match
to both servers and JVMs.
Maynard |
|
| Back to top |
|
|
Maynard Handley
Guest
|
| Posted:
Sat Jan 22, 2005 7:56 am Post subject:
Re: Cell Architecture Explained (MASSIVE AMOUNT OF INFO) |
|
|
In article <cssfcg$fva$1@blue.rahul.net>,
rhn@mauve.rahul.net (Ronald H. Nicholson Jr.) wrote:
| Quote: | In article <name99-42B264.17530821012005@localhost>,
Maynard Handley <name99@name99.org> wrote:
Bottom line is that this thing doesn't resemble any traditional CPU and
is therefore a godawful match to existing languages, compilers and
algorithms.
GPU shader algorithms and languages? Common DSP library/toolbox calls?
|
Which part of
"
(Note, I am not denying that Cell may make a fine Playstation chip.
I AM denying that it will make a fine workstation chip, will take over
the computing world, make all other CPUs obsolete, blah blah blah.)
"
from earlier in the post did you not understand?
Moron!
Maynard
|
|
| Back to top |
|
|
Robert Myers
Guest
|
| Posted:
Sat Jan 22, 2005 7:53 pm Post subject:
Re: Cell Architecture Explained (MASSIVE AMOUNT OF INFO) |
|
|
On Sat, 22 Jan 2005 01:53:48 GMT, Maynard Handley <name99@name99.org>
wrote:
| Quote: | In article <QvadnatFwfzw6W3cRVn-ow@comcast.com>,
"Xenon" <xenonxbox2@xboxnext.com> wrote:
The lack of cache and virtual memory systems means the APUs operate in a
different way from conventional CPUs. This will likely make them harder to
^^^^^
program but they have been designed this way to reduce complexity and
increase performance.
You don't say.
Programming Itanic was a picnic compared to programming this thing; at
least Itanic used a traditional computer architecture.
And yet Intel/HP, with all the money in the world, couldn't make it fly.
Please tell us why IBM/Sony/Toshiba can do what Intel/HP could not.
|
Itanium and Cell both offer advantages for problems that can be
formulated to exploit the architecture. In the case of Itanium, the
advantages have turned out not to be overwhelming. In the case of
stream processors, there are already off-the-shelf GPU's that can
significantly outperform any conventional microprocessor for some
kinds of problems, and the advantage of stream processors will only
grow as feature sizes decrease.
| Quote: | (Note, I am not denying that Cell may make a fine Playstation chip.
I AM denying that it will make a fine workstation chip, will take over
the computing world, make all other CPUs obsolete, blah blah blah.)
|
Predicting the future is really hard. Genuine paradigm shifts are
rare, but I think this one is on its way. The future of computing is
more like what happens on network processors and GPU's than what
happens on x86, PowerPC, or Itanium. The change is being driven by
physics, not marketing.
| Quote: | This may sound like an inflexible system which will be complex to program
and it most likely is but this system will deliver data to the APU registers
So in return for giving up cache, your code has to manually move data
to/from memory. That'll be easy for the compiler to figure out.
|
Of course it won't. But the same problem exists--how do I figure out
how to get the data to where I need it when I need it?--in any
architecture. Cache and registers add a set of tools for dealing with
that problem; they don't make it go away. In the case of at least
some stream processors, there is a _register_ hierarchy: a
low-bandwidth stream register file that faces memory and local
register files that act much like a conventional vector register.
<snip>
| Quote: |
There's (much much, so much) more blather and ranting about how how
fantastic Cell is and how it will solve any problem you can possibly
imagine, but for those of us in the reality-based community, I think the
points I have extracted above are the highlights.
Bottom line is that this thing doesn't resemble any traditional CPU and
is therefore a godawful match to existing languages, compilers and
algorithms. Unless IBM/Sony/Toshiba have, in some other pocket, and kept
an extremely good secret that solves problems many people have been
working on for more than twenty years, you'll be programming this thing
with an assembly language mindset, even if you are nominally using a
high-level language --- like you program AltiVec today. Only it'll be so
much more fun because not only will you be worrying about alignment and
algorithm issues, you'll be trying to juggle fitting your instructions
and data into local memory (we weren't given a size for this but if it
is to run at L1 cache speeds, it can't be wildly far off from say 64K to
512K bytes); none of that getting the cache to just hide the problem for
you if you might want to load from an infrequent used table, handle a
rare exception condition or whatever; it'll be manual segment swapping
all over again. Not to mention the other glorious aspects. You'll be
using some bizarro method to handle coherency. You'll have the engine
that drives your code and handles exceptions and such running on a
different processor from where the compute intensive code lives.
|
Maybe. Somebody likes programming these things because people are
already doing it--just for fun, apparently.
The problems are formidable, but it is early days yet when it comes to
inventing programming models and algorithms for stream processors.
One future I can see is that data (and instructions) will no longer be
associated with memory locations but with labelled packets.
There will always be something that looks like a conventional
microprocessor? Let's wait and see what the promised workstations
look like. Weren't we supposed to have seen them last fall?
The one thing in all this that _really_ gives me pause is that making
it work in the general case seems like getting a dataflow machine to
work in the general case.
There's a really nice summary of GPU programming entering the
mainstream at
http://www.computer.org/computer/homepage/1003/entertainment/
| Quote: | And all this from IBM/Sony/Toshiba, three companies traditionally known
for their openness and willingness to share with the public. I imagine
Intel, AMD and Microsoft are quaking in their boots.
|
They couldn't possibly be less open than the graphics card
manufacturers have been.
RM |
|
| Back to top |
|
|
Ketil Malde
Guest
|
| Posted:
Mon Jan 24, 2005 3:52 pm Post subject:
Re: Cell Architecture Explained (MASSIVE AMOUNT OF INFO) |
|
|
"Xenon" <xenonxbox2@xboxnext.com> writes:
| Quote: | Cell Architecture Explained: Introduction
[...]
250 GFLOPS (Billion Floating Point Operations per Second)
[...]
6.4 Gigabit / second off-chip communication
|
A little bit memory starved, I guess -- or do you have an application
that performs in the neighborhood of fifty FLOPS per *bit*?
-kzm
--
If I haven't seen further, it is by standing in the footprints of giants |
|
| Back to top |
|
|
Douglas Siebert
Guest
|
| Posted:
Mon Jan 24, 2005 7:10 pm Post subject:
Re: Cell Architecture Explained (MASSIVE AMOUNT OF INFO) |
|
|
Ketil Malde <ketil+news@ii.uib.no> writes:
| Quote: | "Xenon" <xenonxbox2@xboxnext.com> writes:
Cell Architecture Explained: Introduction
[...]
250 GFLOPS (Billion Floating Point Operations per Second)
[...]
6.4 Gigabit / second off-chip communication
A little bit memory starved, I guess -- or do you have an application
that performs in the neighborhood of fifty FLOPS per *bit*?
|
The claim made in the Cell paper is that there are 8 Rambus XDR channels at
3.2 GB/s each for a total of 25.6 GB/s (I could have sworn XDR was supposed
to be 6.4 GB/s, but maybe that was down the road) That 6.4 GB/s off chip
communication is the hypertransport equivalent (and also supposed to be per
pin, can't remember how wide that was supposed to be) Not that this gets
it near 250 GLOPS usable for problems larger than a few megabytes.
--
Douglas Siebert dsiebert@excisethis.khamsin.net
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety" -- Thomas Jefferson |
|
| Back to top |
|
|
Andrew Ryan Chang
Guest
|
| Posted:
Mon Jan 24, 2005 10:30 pm Post subject:
Re: Cell Architecture Explained (MASSIVE AMOUNT OF INFO) |
|
|
Xenon <xenonxbox2@xboxnext.com> wrote:
| Quote: | Cell Architecture Explained: Introduction
|
A discussion at Joystiq points out that Mr. Blachford, from who
you stole the article, also explained how to make an antigravity device,
and how light reduces in frequency the further it travels...
http://www.blachford.info/quantum/gravity.html
http://www.blachford.info/quantum/dimeng.html
follow-ups set to rgv.sony; apologies for this idiot crossposter to the
rest of you all.
--
"It's only now, with "Blinded by the Right," that conservatives have grown
a sense of journalistic skepticism when it comes to [David] Brock."
- "Fight or Flight", David Talbot, Salon Apr 17 2002 |
|
| Back to top |
|
|
Doug Jacobs
Guest
|
| Posted:
Tue Jan 25, 2005 1:26 am Post subject:
Re: Cell Architecture Explained (MASSIVE AMOUNT OF INFO) |
|
|
In alt.games.video.xbox CEO Gargantua <gamers@r.lamers> wrote:
| Quote: | Moore's Law is dead, and it's taking Wintel down with it.
|
But is it even needed anymore?
Think about it - how many people *NEED* that 3+Ghz processor? And the
people who do actually need that sort of power are going with SMP or
paralell processing systems already. Even Doom3 is more concerned with
the processor and memory of the graphics card - not with your main CPU.
If anything, the days of the single CPU system are numbered. If you can't
make the individual chip go faster, why not throw more chips at the
problem? This won't lead to a speed-up across the board, but imagine
being able to dedicate a processor to each application you're running on
your system? BeOS used to be able to do this and even let you set how
many processors you wanted dedicated to each process if you wanted. Just
don't set it to 0 CPUs for the OS...bad things would happen ;)
As for margins on its chips, I wouldn't worry about Intel just yet. If
they start doing multiple core processors (one chip, 2 or more CPUs) which
will push their prices along nicely. After all, there's only so much room
on a standard desktop ATX motherboard. |
|
| Back to top |
|
|
Nicholas O. Lindan
Guest
|
| Posted:
Tue Jan 25, 2005 2:23 am Post subject:
Re: Cell Architecture Explained (MASSIVE AMOUNT OF INFO) |
|
|
| Quote: | In alt.games.video.xbox CEO Gargantua <gamers@r.lamers> wrote:
|
This high authority on the issue spake:
| Quote: | Moore's Law is dead, and it's taking Wintel down with it.
|
Pantagruel sez: Then they'll have to start making the software faster.
Won't that be a hoot!
http://www.centaurgalleries.com/Art/00077/I04274-02-500h.jpg |
|
| Back to top |
|
|
David Schwartz
Guest
|
| Posted:
Tue Jan 25, 2005 2:30 am Post subject:
Re: Cell Architecture Explained (MASSIVE AMOUNT OF INFO) |
|
|
"Doug Jacobs" <djacobs@shell.rawbw.com> wrote in message
news:10vamf046cjln91@corp.supernews.com...
| Quote: | If anything, the days of the single CPU system are numbered.
|
They would already be over if companies like Intel and AMD didn't
artificially raise the price of SMP-capable CPUs.
DS |
|
| Back to top |
|
|
Jeremy Williamson
Guest
|
| Posted:
Tue Jan 25, 2005 3:42 am Post subject:
Re: Cell Architecture Explained (MASSIVE AMOUNT OF INFO) |
|
|
"Ronald H. Nicholson Jr." <rhn@mauve.rahul.net> wrote in message
news:cssfcg$fva$1@blue.rahul.net...
| Quote: | In article <name99-42B264.17530821012005@localhost>,
Maynard Handley <name99@name99.org> wrote:
Bottom line is that this thing doesn't resemble any traditional CPU and
is therefore a godawful match to existing languages, compilers and
algorithms.
GPU shader algorithms and languages? Common DSP library/toolbox calls?
--
Ron Nicholson rhn AT nicholson DOT com http://www.nicholson.com/rhn/
#include <canonical.disclaimer> // only my own opinions, etc.
|
???
You do realize that this will still have a GPU, and as a matter of fact Sony
gave up the idea of doing it themselves and gave the contract to nVidia (my
guess was cost vs. bowing to requests from the SW community). Essentially
that means all your basic T&L (including your shader algorithms) are still
done on the GPU.
J |
|
| Back to top |
|
|
Jeremy Williamson
Guest
|
| Posted:
Tue Jan 25, 2005 3:48 am Post subject:
Re: Cell Architecture Explained (MASSIVE AMOUNT OF INFO) |
|
|
"Ketil Malde" <ketil+news@ii.uib.no> wrote in message
news:egu0p7f6aq.fsf@ii.uib.no...
| Quote: | "Xenon" <xenonxbox2@xboxnext.com> writes:
Cell Architecture Explained: Introduction
[...]
250 GFLOPS (Billion Floating Point Operations per Second)
[...]
6.4 Gigabit / second off-chip communication
A little bit memory starved, I guess -- or do you have an application
that performs in the neighborhood of fifty FLOPS per *bit*?
-kzm
--
If I haven't seen further, it is by standing in the footprints of giants
|
GPUs do. Stages and stages of pure logic circuitry. On this beast, every
CPU/APU would have to be executing out of cache of course.
Memory starved is par for the course. One of those issues that increases as
we move forward.
J |
|
| Back to top |
|
|
Ronald H. Nicholson Jr.
Guest
|
| Posted:
Sat Jan 29, 2005 6:13 am Post subject:
Re: Cell Architecture Explained (MASSIVE AMOUNT OF INFO) |
|
|
In article <ct3tks$8gj$1@news01.intel.com>,
Jeremy Williamson <jeremiah.d.williamson@NOSPAMintel.com> wrote:
| Quote: |
"Ronald H. Nicholson Jr." <rhn@mauve.rahul.net> wrote in message
news:cssfcg$fva$1@blue.rahul.net...
In article <name99-42B264.17530821012005@localhost>,
Maynard Handley <name99@name99.org> wrote:
Bottom line is that this thing doesn't resemble any traditional CPU and
is therefore a godawful match to existing languages, compilers and
algorithms.
GPU shader algorithms and languages? Common DSP library/toolbox calls?
....
You do realize that this will still have a GPU, and as a matter of fact Sony
gave up the idea of doing it themselves and gave the contract to nVidia (my
guess was cost vs. bowing to requests from the SW community). Essentially
that means all your basic T&L (including your shader algorithms) are still
done on the GPU.
|
Yes, but aren't people experimenting with using shader and DSP languages
and tools for stuff that has nothing to do with the workstation display
or audio output? The question is whether this software is commercially
interesting and whether this cell device is more suited for this stuff
than the GPU's on which these algorithm were developed.
IMHO. YMMV.
--
Ron Nicholson rhn AT nicholson DOT com http://www.nicholson.com/rhn/
#include <canonical.disclaimer> // only my own opinions, etc. |
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in