Extreme Multithreading on a Chip

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

Comments

eXtreme multithreading?

[ObviousGuy]

Better wear a helmet and knee and elbow pads.

Re:eXtreme multithreading?

[Randolpho]

And in a year, Disney will be animating it as "hip kids-stuff" *cough* Goof Troop Movie *cough*.

Re:eXtreme multithreading?

[Directrix1]

Whatever, in a year Disney will be producing animatronic wives that are perfect in every respect, in a male dominated society :-P.

Hard to program?

[moosesocks]

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?

[Circuit Breaker]

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

Re:Hard to program?

[WindBourne]

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 somebdoy in your group is).

Re:Hard to program?

[Pseudonym]

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.

Re:Hard to program?

[WatertonMan]

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 produce. Right now most desktop Solaris based machines you buy are woefully underpowered for the price. About on part with Apple machines but without the nice environment. (IMO)

Which brings us to Sun's other problem. Apple has lousy hardware at the moment but a rather amazing desktop Unix environment. Further it seems to get only better and better. The next iteration of OSX is due in a couple of months. X11 support is exemplary. Further, unlike the desktops of Linux or Solaris, Apple has most standard productivity applications, an amazing application scripting environment, and has purchased many high end graphic and sound application companies. Right now Apple's achilles heel is hardware that sucks relative to x86 systems. But it is widely expected that when OSX 10.3 is released that 970 systems will at a minimum be announced and demonstrated. That'll put Apple hardware within 10% of x86 hardware - although the price/performance is still up in the air.

Given all this it seems like Sun wants to compete with both Linux and Apple. It can't compete with the price/ performance of Linux. It can't compete with the maturity, elegance, and number of applications of OSX. So exactly how does it plan to compete?

Re:Hard to program?

[WatertonMan]

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.

Re:Hard to program?

[Anonymous Coward]

The programming's already been done. It's designed to run Oracle, apache and various other server applications. Oh, and don't forget Solaris.

IBM too I think...

[RalphBNumbers]

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?

Re:IBM too I think...

[Anonymous Coward]

Of course, this is slashdot, so if it comes from Sun it must be rubbish, but if it comes from IBM it must be really good.

Cluster?

[dacarr]

Imagine a beowulf cluster of these!

Tera Multithreaded computer

[fitten]

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

Re:Tera Multithreaded computer

[fini]

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.

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

Intel

[e8johan]

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

Re:Intel

[makapuf]

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 cannot improve much in GHz, then you will try to modify your software and hardware architecture to make it faster. Not before.

Re:Intel

[e8johan]

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 binaries (i.e. no "...[imposed] multithreaded standard for programming to improve performance..." just a better design.

Compiler support is the flaw

[IanBevan]

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

I appreciate that this article is discussing Sun technology. 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).

Re:Compiler support is the flaw

[Xpilot]

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.

Re:Compiler support is the flaw

[Xpilot]

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.

Re:Compiler support is the flaw

[makapuf]

or if your compiler doesn't support them, you might as well manually patch the binary.

Re:Compiler support is the flaw

[turgid]

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.

Re:Compiler support is the flaw

[pmz]

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, the multi-threading support in these new CPUs will be abstracted by the kernel APIs, meaning most programmers and compilers really won't notice the change from a regular UltraSPARC to the super-mega-32-thread-UltraSPARC. Sun is serious when they say "binary compatibility" (all the way from vintage SPARCstation up to brand new Sun Fire 15K; SPARC v9 is a superset of SPARC v8).

Re:Compiler support is the flaw

[IanBevan]

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 user mode libraries, such as pthreads, are completely reliant upon kernel support to implement their functionality.

My point was that functionality offered by chip manufacturers usually requires support from compiler manufacturers. However I accept that this argument does not *appear* to hold for this new multithreading technology. However, I would not be the least bit surprised to learn that there are certain "optimisations" (i.e. instructions) that while not strictly required, would enhance performance if used. Which requires compiler support (or possibly kernel support).

Perhaps another question is how long the Sparc line will really last. Is Sun's recent foray into the Intel/Linux forum placing the writing on the wall for their server hardware ?

Oh, and FYI this has absolutely nothing whatever to do with Windows, Unix or any other specific operating system.

single threaded is very easy programming

[Anonymous Coward]

Imagine millions of transistors to build a lot of cores of i486 on a chip (= millions to build stupid P4).

JCPM (copyright)

Flaw?

[Anonymous Coward]

Flaw? What flaw? Companies like Sun that develop their own hardware and software generally do so in close cooperation between the departments. If you'd read the article you'd realise that this new processor technology is to do with multithreading, which is generally done by the programmer, not the compiler. Also, you can not compare Sun's compilers on UltraSPARC to Microsoft's compilers on intel, AMD and various other clone processors. MMX has nothing to do with multithreading. It is SIMD (single instruction multiple data) for integer operations. Sun does not have to stick to the lowest common denominator. They just have to support their own chips with their own instruction set and their own particular optimisation strategies. Anyway, what's the point? You won't believe me. Were you just trolling?

SPARC: overpriced, underpowered

[r4lv3k]

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