Slashdot Mirror

← Back to Stories (view on slashdot.org)

Extreme Multithreading on a Chip

Posted by chrisd on from the less-chips-more-mips dept.

kid writes "There's an interesting interview with Dr. Marc Tremblay at Ace's Hardware. Dr. Tremblay is a distinguished engineer at Sun and the co-architect of the UltraSPARC processor. He is currently working on a processor that is claimed to deliver 30 times the performance of current CPUs utilizing an agressive multi-core/multi-threaded architecture. He talks about upcoming highly multithreaded CPUs from Sun as well as a wide range of problems facing today's CPU designers, from branch mispredictions to DRAM latency/bandwidth and power dissipation, and the ways in which he is working on solving them."

7 of 29 comments (clear)

  1. eXtreme multithreading? by ObviousGuy · · Score: 2, Funny

    Better wear a helmet and knee and elbow pads.

    --
    I have been pwned because my /. password was too easy to guess.
  2. Hard to program? by moosesocks · · Score: 3, Interesting

    I remember that BeOS was extremely multi-threaded, which made it a pain to effectively write complex software applications for. Wouldn't this also be the case for the SPARC.

    That being said, multi-threaded processing certainly speeds up an OS. BeOS is by far the fastest OS i've ever used.

    --
    -- If you try to fail and succeed, which have you done? - Uli's moose
    1. Re:Hard to program? by Circuit+Breaker · · Score: 4, Informative

      When you say "fast", do you mean "responsive"?

      There's no speed magic to multithreading on a single thread single CPU system - actually, preemptive multitasking can only reduce raw CPU power.

      For desktop systems, responsiveness is far more important than raw speed - but Sun is in the server business, in which desktop-style responsiveness is less important.

      Furthermore, do not confuse CPU threads with O/S threads; CPU threads may just as well run distinct processes which have no relation to each other - in fact there are architectures that use this as an advantage and do away with a memory cache.

      Multiple threads make software hard to develop (and to debug and test). Multiple processes, essentially threads without a shared address space, much less so. Assuming, of course, that the address space is NOT shared....

    2. Re:Hard to program? by Pseudonym · · Score: 2, Insightful
      For desktop systems, responsiveness is far more important than raw speed - but Sun is in the server business, in which desktop-style responsiveness is less important.

      That's true, but threads are just as important on the server. With the exception of serving read-only data (e.g. web servers, DNS servers), server applications rarely fit into the independent-address-space model. As soon as a client can modify state that others may want (and assuming you need multiprocessor scalability, of course) threads are precisely what you need.

      Multiple threads make software hard to develop (and to debug and test).

      You have to remember, though, that threads are there to help solve difficult problems. Such software is hard to develop and debug and test no matter what solution you use.

      --
      sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
  3. Cluster? by dacarr · · Score: 2, Funny

    Imagine a beowulf cluster of these!

    --
    This sig no verb.
  4. Tera Multithreaded computer by fitten · · Score: 2, Informative

    It's been done for a while. Check out

    http://www.supercomp.org/sc98/TechPapers/sc98_Fu ll Abstracts/Brunett1063/Index.htm

    to see about the Tera Multithreaded computer. 128 hardware threads per single cpu. It was interesting and was actually built (I saw a few).

  5. Intel by e8johan · · Score: 2, Interesting

    It is nice to see that (non-super-computing) people finally come to the conclusion that clock speed isn't everything. All students studying computer architecture learns about the help of parallel tasks. Yet it seems as if everything has been about MHz and GHz the last ten-fifteen years. This is probably not due to the engineers, but rather, due to the Intel marketing department. What surprises me is how many engineers that followed...