In article <o7-dnYRebucXNG3cRVn-oA@comcast.com>, xenonxbox2@xboxnext.com says...> > "R Adsett" <radsett@junk.aeolusdevelopment.cm> wrote in message > news:QsmdnbcqHvbAD23cRVn-gg@rogers.com... > > In article <f4OdncWZFpIT423cRVn-rA@comcast.com>, xenonxbox2@xboxnext.com > > says... > > > *I* am not saying anything. If that's what the article says, then > that's > > > what it says. > > > I will leave it for the tech-heads to figure this stuff out. > > > > Umm, did you really just say that you don't understand an article you > > wrote? > > > > Robert > > > > > Uhhhhhh are you trying to suggest that I wrote all of that?Since you didn't credit anyone else (or post it as a link), it's either that or plagiarism. I took the approach of assuming the lesser evil. Robert
The 2005 ISSCC
Started by ●January 20, 2005
Reply by ●January 21, 20052005-01-21
Reply by ●January 21, 20052005-01-21
Xenon wrote:> *I* am not saying anything. If that's what the article says, then > that's what it says. > I will leave it for the tech-heads to figure this stuff out.You'll have to forgive Xenon. Aside from cutting and pasting about a terabyte's worth of crap per day, he often doesn't even bother providing the source. He's like the Bizarro World version of a regular poster, who simply pastes a link and lets you decide for yourself if you want to read it. Xenon wants you to read it, but often doesn't bother telling you where it came from. -Z-
Reply by ●January 21, 20052005-01-21
Paul Russell wrote:> The Don wrote: >> "Xenon" <xenonxbox2@xboxnext.com> wrote in message >>> >>> >>>Uhhhhhh are you trying to suggest that I wrote all of that? >>> >>> >> >> >> NO - you are suggesting that by not drawing any reference to the actual >> creator or source of the article that YOU posted. >> >> > > xenon apparently plagiarised the article from Mr Nicholas Blachford: > <http://www.blachford.info/computer/Cells/Cell1.html>.Having had a quick scan of the material there it seems like the DMAC becomes the potential bottle-neck. Looking at the architecture it is hardly surprising that the chip is running at 85C on a heat-sink. It is probably not going to be a processor I'd be considering for any embedded project anytime soon. PS:- Beware when responding to other messages in this thread as they are cross-posted to a wide variety of other newsgroups. I have trimmed to just this one. -- ******************************************************************** Paul E. Bennett ....................<email://peb@a...> Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/> Mob: +44 (0)7811-639972 .........NOW AVAILABLE:- HIDECS COURSE...... Tel: +44 (0)1235-811095 .... see http://www.feabhas.com for details. Going Forth Safely ..... EBA. www.electric-boat-association.org.uk.. ********************************************************************
Reply by ●January 21, 20052005-01-21
Xenon wrote:>Cell Architecture Explained: IntroductionNext time, just post the link, idiot. *plonk*
Reply by ●January 21, 20052005-01-21
In alt.games.video.sony-playstation2 Zackman <zackman@spamisevilearthling.net> wrote:> You'll have to forgive Xenon. Aside from cutting and pasting about a > terabyte's worth of crap per day, he often doesn't even bother providing the > source. He's like the Bizarro World version of a regular poster, who simply > pastes a link and lets you decide for yourself if you want to read it. Xenon > wants you to read it, but often doesn't bother telling you where it came > from.Or even what he thinks about it. In this case, it seems that he doesn't even understand what he posted.
Reply by ●January 21, 20052005-01-21
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. (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.)> 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 registersSo 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.> 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 local2 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.> 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
Reply by ●January 21, 20052005-01-21
Maynard Handley wrote:> (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
Reply by ●January 21, 20052005-01-21
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.
Reply by ●January 22, 20052005-01-22
In article <cssfcg$fva$1@blue.rahul.net>, rhn@mauve.rahul.net (Ronald H. Nicholson Jr.) wrote:> 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> -- > Ron Nicholson rhn AT nicholson DOT com http://www.nicholson.com/rhn/ > #include <canonical.disclaimer> // only my own opinions, etc.
Reply by ●January 22, 20052005-01-22
On Sat, 22 Jan 2005 01:53:48 GMT, Maynard Handley <name99@name99.org> wrote:>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.>(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.>> 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>> >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/>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