Slashdot Mirror


More Interest In Parallel Programming Outside the US?

simoniker writes "In a new weblog post on Dobbs Code Talk, Intel's James Reinders discusses the growth of concurrency in programming, suggesting that '...programming for multi-core is catching the imagination of programmers more in Japan, China, Russia, and India than in Europe and the United States.' He also comments: 'We see a significantly HIGHER interest in jumping on a parallelism from programmers with under 15 years experience, verses programmers with more than 15 years.' Any anecdotal evidence for or against from this community?"

5 of 342 comments (clear)

  1. Duh? by gustolove · · Score: 4, Informative

    Old programmers don't want to learn new things -- trust the tried and true.

    Young bucks want to be on the cutting edge to get the jobs that the old people already have.

    ----

    Oh, and the people see the benefit in the other countries more than those in the U.S.? Probably not, we're just lazy American's though.

    1. Re:Duh? by foobsr · · Score: 3, Informative

      the latest thing

      1960: E. V. Yevreinov at the Institute of Mathematics in Novosibirsk (IMN) begins work on tightly-coupled, coarse-grain parallel architectures with programmable interconnects. ( c.f. )

      An extra core or so on a desktop is nice, beyond that they really won't be anywhere near the speedup its hyped.

      And of course any virtual reality scenario will not profit from extra power.

      CC.

      --
      TaijiQuan (Huang, 5 loosenings)
    2. Re:Duh? by smallfries · · Score: 3, Informative

      What do you mean by "parallelize well"? Normally people would use that phrase to imply fine-grained parallelism in the problem but I suspect that you are using it differently. For example when you say that compilation parallelizes well are you talking about coarse-grain parallelism across compilation-units? This is not really a single instance of a problem being computed in parallel, but rather many independent instances of a problem. If you are willing to use many independent instances of a problem then the coarse-grain parallelism will always scale "well" - i.e linearly in the number of cores. But this does not provide a speedup in many real-world applications.

      In your compilation example, it is easy to get speedups at the compilation level using something like make -jN. But this assumes that each unit is independent. If you want to apply advanced global optimisations then this is not always the case, and then you hit the harder problem of parallelizing the compilation algorithms rather than just running multiple instances. It's not impossible but I'm not aware of any commercial compilers that do this.

      --
      Slashdot: where don knuth is an idiot because he cant grasp the awesome power of php
    3. Re:Duh? by CastrTroy · · Score: 4, Informative

      Most people who do anything are mediocre. Otherwise, mediocre would be redefined. It's like saying, half the people in the class scored below average. The fact that half the people scored below some value determines what the value of average is.

      --

      Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
    4. Re:Duh? by Inoshiro · · Score: 3, Informative

      "And of course any virtual reality scenario will not profit from extra power."

      It's more a matter of what kind of speedup you see, and what algorithm you start with.

      If your algorithm is serial, and there is no parallelism to speed it up, you're not going to see any speed increase. This applies to a lot of things, such as access to the player-character status variables (all cores use the same memory address, so they need a mutex or other synchronization anyway). Any AI-NPC interactions would likely need to be coordinated. You could divide the large stuff across some collection of cores (physics core, AI core, book-keeping core, input core), but not all of those will break down further (so an 80 core machine is a limited speedup over a 4 core machine -- which is, itself, a limited speedup over a basic 2-core machine for most people).

      The easy things to breakup are embarrassingly parallel problems (like certain graphics activities), and they are being broken up across GPUs already. Algorithms, even if they are entirely easy to parallelize, are still linear. To be 10 times faster, you need 10 processors (this is why GPUs have a lot of simple graphics pipelines and shader processors -- they're throwing more hardware at the problem). If a problem is simply too big (you need to be 1000 times faster, or exponential and beyond algorithms), more hardware isn't going to help.

      People seem to think that parallel programming will make the impossible into something possible. That's not true. Proving NP = P and coming up with efficient algorithms for certain things will. More hardware won't -- it'll just make things that were O(n) or O(log n) [for a sufficiently large n, like the number of pixels in a 1920x1200 monitor] possible. It won't affect O(n^2) and above.

      --
      --
      Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.