New CELL Article Online

Article: CELL Microprocessor III
By: fastpathguru (fastpathguru.delete@this.yahoo.com), August 6, 2005 6:29 am
Room: Moderated Discussions
Deadmeat (deadmeatoa@yahoo.com) on 8/6/05 wrote:
---------------------------
>> Come on... SPUFS is just a single example of how SPEs can be abstracted in Linux.
>
>Actually, it is the APU programming model at the lowest level within the user process;
>the one most likely used by performance-demanding applications(games).

You may very well be correct here, that a thread is required to kick off each SPU. But I think you're making the assumption (mistake) that the thread doing the kicking is also a "work" thread, one that requires calculation. In most of the programming models discussed in the slideshow, the SPUs are given a higher degree of autonomy. Take the "job queue" model for instance: The kicking thread kicks and blocks forever while the SPU(s) sit(s) there handling orders delivered by one or more threads whose number is unrelated to the number of SPUs. For some applications this will be the most efficient model. For other apps, other models will be better.

>> Don't make the mistake of thinking that's the only, or highest-performance, or
>easiest-to-implement programming model.
>
>The others are "abstrated" models built on top of APU file system. They aren't as
>flexible as APU file system and takes a toll on performance.

I disagree with all three statements; A) The "file system" model is just one way of presenting the SPE resources, B) & C) see above.

>> Start on slide 24. You may find it enlightening.
>
>I saw it last May, didn't tell me what I needed to know.

But it directly addresses your concerns. Your "work threads blocking on SPEs" model clearly doesn't describe the range of programming models available.

>> Think about accelerating the 5% of code that takes 95% of the processing time
>in applications that are specialized enough to warrant the work.
>
>While I am very much well-aware of 5%/95% rule, the chances of the thread being in APU
>process space is not 95%, because of limited memory size.

I think you have the wrong impression of what is appropriate to run in the SPEs.

>> The explicitly-managed cache can hurt performance if used ignorantly, but when
>leveraged properly, has the potential to eliminate access latencies completely.
>
>Why put additional burden on developers???

Answered below! "The whole key..."

>> The whole key to Cell-like heterogenous architectures is that applications that
>go through the pain of being tailored to them will ride on and benefit from a GPU-like rate of performance growth.
>
>So called GPU-like rate of performance growth assumes no data dependency between
>threads; which is almost not the case with game code.

No, it assumes that appropriately written software will scale more directly in performance with both the performance and number of the coprocessor engines, and the environment they sit in (i.e. memory system.)

>> It's likely why Sony is looking at PS3 as a 10-year platform
>
>No console lasts for 10 years, in spite of what marketting people want you to believe.

See below, "Not because..."

>> Not because they expect it's so powerful that it will still be relevant in 2015,
>but because it will scale like mad, far faster than conventional, homogenous "jack
>of all, master of none" architectures.
>
>CELL is not very scalable, it still introduces the kind of hardware dependency
>that does not allow old code to run well on the newer one. CELL's performance depends
>on the number of threads the developer creates(more the better), but there are only
>so many threads that the developer can create and manage. Suppose you have a program
>tuned for the 7-APU CELL model. Will this code run faster on the 16-APU version or a CELL SMP board? Nope.

Strawman: If you tuned your algorithm specifically for 7 SPEs, you made your bed now sleep in it. There are many other ways of programming Cell-like chips that WILL scale with the number of SPEs. Not everybody suffers from your lack of imagination. (I don't mean to be harsh, but your argument is ignoring lots of evidence that contradicts it.)

Your whole argument is analagous to saying, "multi-core x86 isn't scalable because single-threaded apps can't use the other core(s), and programming multi-threaded apps is hard."

fpg
< Previous Post in ThreadNext Post in Thread >
TopicPosted ByDate
New CELL Article OnlineDavid Kanter2005/08/02 11:32 AM
  New CELL Article Onlinemas2005/08/02 12:46 PM
    New CELL Article Onlinemas2005/08/02 12:53 PM
    New CELL Article OnlineDavid Wang2005/08/02 01:46 PM
      New CELL Article Onlinefastpathguru2005/08/02 04:05 PM
        New CELL Article OnlineDavid Wang2005/08/02 06:27 PM
          New CELL Article OnlinePanajev2001a2005/08/03 03:26 AM
            New CELL Article OnlineDavid Wang2005/08/03 11:28 AM
              New CELL Article OnlineDeadmeat2005/08/04 01:05 PM
                New CELL Article OnlineDavid Wang2005/08/04 05:47 PM
                  New CELL Article OnlineDeadmeat2005/08/04 07:04 PM
                    New CELL Article Onlinejohn evans2005/08/04 08:30 PM
                      New CELL Article OnlineDeadmeat2005/08/05 12:10 PM
                        New CELL Article OnlineLinus Torvalds2005/08/05 06:21 PM
                          New CELL Article OnlineDeadmeat2005/08/05 07:33 PM
                            New CELL Article Onlinefastpathguru2005/08/05 10:36 PM
                              New CELL Article Onlinejohn evans2005/08/05 10:51 PM
                              New CELL Article OnlineDeadmeat2005/08/06 04:09 AM
                                New CELL Article Onlinefastpathguru2005/08/06 06:29 AM
                                  New CELL Article OnlineDeadmeat2005/08/07 04:06 PM
                    New CELL Article OnlineDavid Wang2005/08/04 09:03 PM
                      New CELL Article OnlineDeadmeat2005/08/05 12:21 PM
                        New CELL Article OnlineDavid Wang2005/08/05 11:51 PM
              New CELL Article OnlineDavid Wang2005/08/06 12:00 AM
                New CELL Article OnlineDeadmeat2005/08/07 03:39 PM
                  New CELL Article OnlineDavid Wang2005/08/08 01:57 PM
                    New CELL Article OnlineDeadmeat2005/08/08 02:55 PM
                      New CELL Article OnlineDavid Wang2005/08/08 03:37 PM
                        New CELL Article OnlineDeadmeat2005/08/08 05:05 PM
                          New CELL Article OnlineDavid Wang2005/08/08 05:47 PM
                            New CELL Article OnlineDeadmeat2005/08/08 06:25 PM
                              Implausible at best, irrational most likely...David Kanter2005/08/08 06:51 PM
                                Implausible at best, irrational most likely...Deadmeat2005/08/09 10:26 AM
                              New CELL Article OnlineDavid Wang2005/08/08 07:46 PM
                                New CELL Article OnlineDeadmeat2005/08/09 10:36 AM
                                  New CELL Article OnlineDavid Wang2005/08/09 11:12 AM
                                    New CELL Article OnlineDeadmeat2005/08/09 01:26 PM
                                      New CELL Article OnlineDavid Wang2005/08/09 02:36 PM
                                New CELL Article OnlineAaron Spink2005/08/09 02:57 PM
                                  New CELL Article OnlineDavid Wang2005/08/10 10:06 AM
                    New CELL Article OnlineSerge Monkewitz2005/08/09 01:18 PM
                      New CELL Article OnlineDeadmeat2005/08/09 01:30 PM
                        New CELL Article OnlineVitaly Vidmirov2005/08/11 01:36 AM
      New CELL Article OnlineAnonymous2005/08/03 04:11 PM
        New CELL Article Onlinefastpathguru2005/08/03 05:19 PM
          New CELL Article Onlinemas2005/08/03 07:59 PM
            New CELL Article OnlineJosé Javier Zarate2005/08/04 05:20 AM
              New CELL Article Onlinemas2005/08/04 05:27 AM
          New CELL Article Onlinemas2005/08/05 06:50 AM
  New CELL Article OnlinePiedPiper2005/08/02 09:02 PM
Reply to this Topic
Name:
Email:
Topic:
Body: No Text
How do you spell purple?