Are any of you guys familiar with the SAI Architecture? http://iris.usc.edu/~afrancoi/sai/
I guess you could classify it as a async message passing model (sort of). It has some nice features and may be a good fit to the CBE platform. Is there anyone familiar with SAI and CBE who has a view on this? > -----Original Message----- > From: Eugen Leitl [mailto:[EMAIL PROTECTED] > Sent: 27 November 2005 7:31 PM > To: [email protected] > Subject: Re: [agi] /. [Unleashing the Power of the Cell Broadband Engine] > > On Sun, Nov 27, 2005 at 10:21:07AM -0800, [EMAIL PROTECTED] wrote: > > > In general, I think it's fair to say that there's a lot of concern in > the > > game dev community about how useful the Cell will really be. It will > > certainly have far less effective, usable power than the raw specs > suggest. > > Repeat after me: "it depends on your problem". Some (many) codes will > bite. > Some will run like rabid foxes on meth. > > > There are a couple of specific issues: > > > > - Multithreading is really hard to work with. Even for a programmer > with > > extensive experience, multithreaded code is simply slower to write and > > harder to debug than single-threaded code. This is a fundamental > problem > > that is largely unfixable by tools and libraries. > > Yes, people are lousy at parallelism. But it doesn't matter: the easy > payoffs on ramping up clock of single cores are past. It's time to dive > into the parallel programming model. If you can't state your problem > in terms of asynchronous message passing (not just threads), you've got > a problem on your hands that will only get worse with time. > > > - The Cell programming model is asymmetrical (ie, not all processors are > > identical), which obviously makes things harder. > > 8 SPEs are homogenous allright. The main CPU is just the caretaker, and > runs > your vanilla OS, and feeds the SPEs (or sets them up to do the work > by themselves, and just twiddles thumbs). > > > - The individual processors in the Cell are relatively underpowered by > > today's standards. > > Not if you consider in-register SIMD performance, and codes running > directly out of their individual on-die memory areas. > > > - Perhaps most critically, the SPEs just don't have enough memory to > > actually do much real work. There are very few interesting problems > that > > fit in 256K, and the performance penalty for accessing "external" memory > is > > You can assume 2 MByte on-die memory. > > > very substantial. > > How is that different from today's machines? > > > The first three points above apply to a somewhat lesser extent to the > Xbox > > 360 processor also. > > The Xbox is a closed shop. It doesn't matter which hardware it runs, > it will never become available to generic programming projects. > > > Although it's clearly true that parallelism is the future, don't > > underestimate the difficulties it will bring. You can make a pretty > strong > > It doesn't matter: you will have to deal with the problem sooner or later, > anyway. The longer you wait, the worse it's going to get. > > > case that one effect of the move to parallelism will be to substantially > > raise the skill bar for professional programmers. A mediocre programmer > who > > might be able to produce useful code in the old world will likely be a > net > > liability in the modern world, simply because parallel architectures > make it > > so easy to make catastrophic mistakes. > > AI is not a domain well-suited for mediocre programmers. > > > Finally, remember that consoles are approximately closed platforms, > meaning > > that you can't just buy one and start writing code for it. > > This is only true as long as Sony doesn't ship a Linux kit (it took them > a while to ship one for the PS2, but I presume they learned something > since). > IBMs Cell-based blades (assuming, they will ever ship) will be probably > not priced competitively, agreed. > > The current sweet spot is AMD64, especially dual-core. By the time the > Cell > ships it will be cheap DDR2 dual cores, or even DDR4 quad cores. > > -- > Eugen* Leitl <a href="http://leitl.org";>leitl</a> > ______________________________________________________________ > ICBM: 48.07100, 11.36820 http://www.leitl.org > 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE > > ------- > To unsubscribe, change your address, or temporarily deactivate your > subscription, > please go to http://v2.listbox.com/member/[EMAIL PROTECTED] > > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.1.362 / Virus Database: 267.13.8/184 - Release Date: 11/27/2005 > > -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.362 / Virus Database: 267.13.8/184 - Release Date: 11/27/2005 ------- To unsubscribe, change your address, or temporarily deactivate your subscription, please go to http://v2.listbox.com/member/[EMAIL PROTECTED]
