By: Scott Bolt (sbolt.delete@this.comcast.net), March 16, 2008 11:36 am
Room: Moderated Discussions
I believe that your assumptions are correct in the consumer desktop market.

People will find that dual core is fast enough for the vast majority of typical desktop loads. Even single core will likely do (as we are about to find out when Intel releases their "Atom" lineup).

Gamers will gravitate to consoles, desktop users will be fine with the number of cores and the state of parallelism that we currently have for quite some time.

..... but server and workstation use cases will most surely graduate to something MUCH more parallel that what we have today.

In this market, the relatively small number of applications will surely be re-compiled with more efficient parallel optimized compilers. Operating systems will be tweaked to allow more ease of maximizing hardware usage, and programmers for these high end applications will be trained in the latest and greatest methods for parallel programming.

As a home user, I don't really mind TOO much if my latest high def encoding takes the same amount of time to render as it takes to run ...... but a company that does this for a living?

Same goes for database and other server apps.

Linus Torvalds (torvalds@osdl.org) on 2/15/08 wrote:
>David Patterson (pattrsn@cs.berkeley.edu) on 2/15/08 wrote:
>>* The goal is to raise the level of abstraction to allow
>>people the space that we'll need to be able to make the
>>manycore bet work, rather than to be hamstrung by 15-year
>>old legacy code written in 30-year old progamming
>Well, you basically start off by just assuming it can
>work, and that nothing else can.
>That's a big assumption. It's by no means something you
>should take for granted. It's a wish that hasn't come to
>fruition so far, and quite frankly, I don't think people
>are really any closer to a solution today than they were
>two decades ago.
>The fact that you can find application domains where it
>does work isn't new.
>We've had our CM-5's, we've had our Occam programs, and
>there's no question they worked. The question is whether
>they work for general-purpose computing, and that one is
>still unanswered, I think.
>>* Apparently some readers skipped the part where we looked
>>at the SPEC benchmarks, the embedded EEMBBC benchmarks,
>>and then interviewed experts in databases, machine
>>learning, graphics as well as high performance computing
>>in trying to see if there was a short list of design
>No, I don't think people missed that. But you simplified
>those questions down to the point where it's not clear that
>your answers matched the question any more.
>For example, sure, you can claim that gcc boils down to
>a "finite state machine". In a sense pretty much
>anything boils down to that (are we Turing compete
>or not?), but that doesn't really say that the dwarf would
>be at all representing what gcc really ends up doing.
>And one of the projects I work on is almost purely a
>"graph traversal with hashing", so it should match your
>dwarf to a T, but the thing is, the biggest issue is how
>to minimize the size of the graph you have to traverse, not
>to traverse it as fast as possible. The problem isn't CPU
>time, it's memory and IO footprint.
>And I don't think that is unheard of elsewhere. The core
>algorithm could well be parallelizable, but the problem
>isn't the linear CPU speed, it's the things outside
>the CPU.
>>Our bet is that the best applications, the best programming
>>languages, the best libraries,... have not yet been
>If we are looking at a 100+ core future, I certainly agree.
>>If we as field can succeed at this amazingly difficult
>>challenge, the future looks good. If not, then performance
>>increases we have relied upon for decades will come
>>to an abrupt halt, likely dimishing the future of the IT
>Here's my personal prediction, and hey, it's just that: a
>(a) we'll continue to be largely dominated by linear
>issues in a majority of loads.
>(b) this may well mean that the future of GP computing
>ends up being about small, and low power, and being
>absolutely everywhere (== really dirty cheap).
>IOW, the expectation of exponential performance scaling
>may simply not be the thing that we even want. Yeah,
>we'll get it for those nice parallel loads, but rather
>than expect everything to get there, maybe we should just
>look forward to improving IT in other directions than pure
>If the choice becomes one of "parallel but fast machines"
>and "really small and really cheap and really low power
>and 'fast enough' ones with just a coule of cores", maybe
>people will really pick the latter.
>Especially if it proves that the parallel problem really
>isn't practically solvable for a lot of things that people
>want to do.
>Pessimistic? It depends on what you look forward to.
< Previous Post in ThreadNext Post in Thread >
TopicPosted ByDate
Multicore is unlikely to be the ideal answer.Anders Jensen2008/02/14 04:24 AM
  And the links..Anders Jensen2008/02/14 04:25 AM
    Disappointing..Linus Torvalds2008/02/14 10:17 AM
      Disappointing..Mark Roulo2008/02/14 11:03 AM
        LOL (NT)Linus Torvalds2008/02/14 05:43 PM
      Disappointing..David Patterson2008/02/15 11:53 AM
        Disappointing..Linus Torvalds2008/02/15 05:01 PM
          Disappointing..anon2008/02/15 08:54 PM
            Disappointing..JasonB2008/02/19 07:45 PM
          Disappointing..Ilya Lipovsky2008/02/22 06:27 PM
          Disappointing..Scott Bolt2008/03/16 11:36 AM
        Need for new programming languagesVincent Diepeveen2008/02/19 06:18 AM
          Need for new programming languagesPete Wilson2008/02/24 11:41 AM
        Disappointing..Zan2008/02/25 10:52 PM
      Disappointing..Robert Myers2008/02/19 09:47 PM
        Disappointing..Fred Bosick2008/02/22 06:38 PM
          Disappointing..Robert Myers2008/03/01 01:17 PM
        The limits of single CPU speed are here.John Nagle2008/03/14 10:55 AM
          The limits of single CPU speed are here.Howard Chu2008/03/15 01:02 AM
            The limits of single CPU speed are here.slacker2008/03/15 08:08 AM
              The limits of single CPU speed are here.Howard Chu2008/03/17 01:47 AM
                The limits of single CPU speed are here.slacker2008/03/17 10:04 AM
    And the links..Howard Chu2008/02/14 12:58 PM
      I take some of that backHoward Chu2008/02/14 01:55 PM
      And the links..Jesper Frimann2008/02/14 02:02 PM
      And the links..Ilya Lipovsky2008/02/15 02:24 PM
        And the links..iz2008/02/17 10:55 AM
          And the links..JasonB2008/02/17 07:09 PM
            And the links..Ilya Lipovsky2008/02/18 01:54 PM
              And the links..JasonB2008/02/18 10:34 PM
                And the links..Thiago Kurovski2008/02/19 07:01 PM
                  And the links..iz2008/02/20 10:36 AM
                And the links..Ilya Lipovsky2008/02/20 03:37 PM
                  And the links..JasonB2008/02/20 06:28 PM
        And the links..JasonB2008/02/17 06:47 PM
          And the links..Ilya Lipovsky2008/02/18 02:27 PM
            And the links..JasonB2008/02/18 10:00 PM
              And the links..JasonB2008/02/19 03:14 AM
              And the links..Ilya Lipovsky2008/02/20 04:29 PM
                And the links..JasonB2008/02/20 06:14 PM
                  And the links..Ilya Lipovsky2008/02/21 11:07 AM
    And the links..Howard Chu2008/02/14 01:16 PM
      And the links..Jukka Larja2008/02/15 03:00 AM
      Berkeley View on ParallelismDavid Kanter2008/02/15 11:41 AM
        Berkeley View on ParallelismHoward Chu2008/02/15 12:49 PM
          Berkeley View on ParallelismDavid Kanter2008/02/15 03:48 PM
            Berkeley View on ParallelismHoward Chu2008/02/17 05:42 PM
              Berkeley View on Parallelismnick2008/02/17 09:15 PM
                Berkeley View on ParallelismHoward Chu2008/02/18 04:23 PM
                  Berkeley View on Parallelismnick2008/02/18 10:03 PM
                    Berkeley View on ParallelismHoward Chu2008/02/19 01:39 AM
                  Berkeley View on Parallelismrcf2008/02/19 12:44 PM
                    Berkeley View on ParallelismHoward Chu2008/02/19 03:25 PM
              Average programmersanon2008/02/18 12:40 PM
        Berkeley View on ParallelismJasonB2008/02/15 08:02 PM
        Berkeley View on ParallelismJasonB2008/02/15 08:02 PM
          Berkeley View on ParallelismDean Kent2008/02/15 08:07 PM
          Berkeley View on ParallelismRay2008/02/20 03:20 PM
            Berkeley View on ParallelismJasonB2008/02/20 06:11 PM
              Berkeley View on ParallelismFritzR2008/02/24 03:08 PM
          rubyinline, etc.nordsieck2008/02/22 03:38 PM
            rubyinline, etc.JasonB2008/02/23 05:53 AM
              rubyinline, etc.nordsieck2008/03/02 01:40 AM
                rubyinline, etc.Michael S2008/03/02 02:49 AM
                  rubyinline, etc.Dean Kent2008/03/02 07:41 AM
                    rubyinline, etc.Michael S2008/03/02 08:19 AM
                      rubyinline, etc.Dean Kent2008/03/02 08:30 AM
                        rubyinline, etc.JasonB2008/03/02 05:26 PM
                rubyinline, etc.JasonB2008/03/02 06:01 PM
                  rubyinline, etc.Anonymous2008/03/03 02:11 AM
                    rubyinline, etc.JasonB2008/03/03 09:40 AM
                      rubyinline, etc.Foo_2008/03/09 09:59 AM
                        rubyinline, etc.JasonB2008/03/10 01:12 AM
                        rubyinline, etc.Gabriele Svelto2008/03/10 02:22 AM
                          rubyinline, etc.JasonB2008/03/10 04:35 AM
                            C++ for beginnersMichael S2008/03/10 05:16 AM
                              C++ for beginnersJasonB2008/03/10 06:35 AM
                          C++Michael S2008/03/10 04:55 AM
                rubyinline, etc.Linus Torvalds2008/03/03 11:35 AM
                  rubyinline, etc.Dean Kent2008/03/03 02:35 PM
                    rubyinline, etc.JasonB2008/03/03 03:57 PM
                      rubyinline, etc.Dean Kent2008/03/03 08:10 PM
                        rubyinline, etc.Michael S2008/03/04 01:53 AM
                          rubyinline, etc.Dean Kent2008/03/04 07:51 AM
                            rubyinline, etc.Michael S2008/03/04 08:29 AM
                              rubyinline, etc.Dean Kent2008/03/04 08:53 AM
                                rubyinline, etc.Michael S2008/03/04 11:20 AM
                                  rubyinline, etc.Dean Kent2008/03/04 02:13 PM
                                    read it. thanks (NT)Michael S2008/03/04 04:31 PM
                  efficient HLL'sPatrik Hägglund2008/03/04 03:34 PM
                    efficient HLL'sWes Felter2008/03/04 09:33 PM
                      efficient HLL'sPatrik Hägglund2008/03/05 01:23 AM
                        efficient HLL'sMichael S2008/03/05 02:45 AM
                          efficient HLL'sWilco2008/03/05 05:34 PM
                            efficient HLL'sHoward Chu2008/03/05 07:11 PM
                              efficient HLL'sWilco2008/03/06 02:27 PM
                    efficient HLL'sanon2008/03/05 08:20 AM
      And the links..Groo2008/02/17 04:28 PM
        And the links..Vincent Diepeveen2008/02/18 02:33 AM
Reply to this Topic
Body: No Text
How do you spell avocado?