Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Sun Microsystems Hardware

Extreme Multithreading on a Chip 29

Posted by chrisd 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."
This discussion has been archived. No new comments can be posted.

Extreme Multithreading on a Chip More

Extreme Multithreading on a Chip

Comments Filter:
  • Better wear a helmet and knee and elbow pads.

  • Hard to program? (Score:4, Interesting)

    by moosesocks ( 264553 ) on Monday March 24, 2003 @10:46PM (#5588343) Homepage
    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.

    • Re:Hard to program? (Score:5, Informative)

      by Circuit Breaker ( 114482 ) on Monday March 24, 2003 @11:37PM (#5588606)
      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....
      • but Sun is in the server business, in which desktop-style responsiveness is less important. Sun started on the desktop and went to server space due to high margins. They also found that when the market drops that servers suffer the most. Sun is quietly preparing a new desktop based on your choice of Linux or Solaris. You will soon be hearing some very interesting news from Sun and others.
        Multiple threads make software hard to develop (and to debug and test). They can be sporting if you are sloppy (or someb
        • Unfortunately Sun returning to the desktop/workstation is probably too little too late.

          Consider that they are going to face competition from two sources. The first is Linux whose desktop offerings, while still weak, are light years ahead of Sun. Even if Sun largely borrows Redhat's playbook and adds a bit more, they still have the hardware problem. They need cheap chips that are fast. They are competing with fast, cheap PC systems that run a desktop environment superior to anything Sun is likely to

      • Re:Hard to program? (Score:3, Insightful)

        by Pseudonym ( 62607 )

        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

    • You don't *need* to multithread everything. Just because you can do something doesn't mean you should do something. Certainly to get the benefits of a multiprocessor machine (or virtual machine) you ought to multithread. However you can often figure out what needs multithreaded fairly easily. I think the complexities of multithreading are usually poor software design and not the process itself.
  • I seem to remember a similar article about IBM doing a much more radical implementation of multithreading on the Power5, but damned if I can find it to link now.

    Anyone seen something relevant?

  • Cluster? (Score:3, Funny)

    by dacarr ( 562277 ) on Monday March 24, 2003 @11:42PM (#5588624) Homepage Journal
    Imagine a beowulf cluster of these!
  • 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).
    • In Tera's case, the goal was to mask the latency of a totally shared uniformed memory. The CPUs were completly cache-less. Their approach was really extreme. It seems they also did a blunder by betting on gallium arsenide, in the words of one of my university professors, a technology that has been the future for the past 25 years ;-)

      So what had to happen happened [npaci.edu].

      Still, Teras were really cool machines. Sigh...

  • Intel (Score:3, Interesting)

    by e8johan ( 605347 ) on Tuesday March 25, 2003 @01:36AM (#5589160) Homepage Journal

    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...

    • It's a simple optimization procedure.
      If you crank up MHz (or instructions per cycle), then every already wruten application can make use of them.
      If you impose a multithreaded standard for programming to improve performance, well, fine, but it is maybe not simpler to rewrite your existing program : either you improve all(cpu-bound) programs by 100% (doubling processing speed for same arch) or you can multiply by 10 1% of the applications. The first one is more effective in the whole scale.
      Of course, when you

      • The thing is that most modern OSs runs more than one task at a them. Just try "ps -a" on your Linux box, or Ctrl-Alt-Delete, Task Manager on you Windows machine and look. Now, don't tell me that architectures that allow several processes to share the CPU have been obsolete up 'till now.

        My guess is that the GHz have far more to do with marketing as that is the field where Intel beats AMD. Performance wise AMD has fought of Intel pretty well running at lower frequencies executing Intel-x86-compatible binarie

  • The key to a processor like this making a genuine difference in real world applications may well come down to compiler support. By far the most prolific compiler on the most prolific OS (Windows) is Microsoft Visual C++. Years on from the introduction of P3/P4/MMX etc. and there is still virtually no support for these technologies in Visual C++. Microsoft, like most (all ?) compiler vendors stick to almost-the-lowest-common-denominator when it comes to instructions sets, which means in this case means bland
    • Uh, from the article:

      Chris Rijk [Ace's Hardware]: And that's entirely hardware based -- does not need any special compilation or software support?

      Dr. Marc Tremblay: That's correct.

    • Years on from the introduction of P3/P4/MMX etc. and there is still virtually no support for these technologies in Visual C++. Microsoft, like most (all ?) compiler vendors stick to almost-the-lowest-common-denominator when it comes to instructions sets, which means in this case means bland-ish Intel.

      AFAIK, if you wanted to use MMX instructions, you had to hand-code the operation yourself in asm. Correct me if I'm mistaken.
    • You Windows people sure have a funny way of looking at things :-) This technology is to do with multi-threading, which is handled by a library, not the compiler, on UNIX systems. This is mentioned in the article. It's also worth noting that companies like Sun that produce hardware and software usually bring both out at the same time, so there's no waiting for compilers to catch up compared to the Windows world, where most developers use Microsoft's compilers and either intel's or AMD's chips.
      • Your comment is not quite correct. You might think that libraries are used to implement threads, but the reality is that non-user-mode threading (i.e. anything approaching a sensible implementation for processors that support page protection) requires access to special instructions on the processor. So, the libraries you talk of are actually kernel mode, and they will certainly be using hand crafted assembler to execute the priveleged instructions required to perform processor level context switching. Any u
    • Even if Sun produce an UltraSparc 4 processor (or whatever) with this technology built in, my guess is that it will be literally years before the popular Solaris compilers catch up (those being Sun Workshop and gcc).

      Sun Workshop (now Forte (now Sun ONE Compiler Suite)) should not be a problem. Sun's compiler has thorough support from generic SPARC v9 output to specific USIII/VIS output. When the USIV comes out, the next version of the compiler will simply have new command-line switches.

      Additionally, th
  • Does this mean the next SPARC servers will finally run as fast as a Xeon running linux? SPARCs are slow and expensive... get rid of 'em! r4lv3k

Slashdot Top Deals

As far as the laws of mathematics refer to reality, they are not certain, and as far as they are certain, they do not refer to reality. -- Albert Einstein

Close