Is Sun's Niagara Server Viagra? 190
argonaut writes "Ace's Hardware has an in-depth article on Niagara -- Sun's upcoming parallel server processor with 8 cores and 4 threads each. The article discusses the chip's radical architecture and what kind of performance can be expected from it in traditionally thread-heavy server applications like web hosting, databases, and other multi-user applications. Given the recent cancellation of the UltraSPARC V, it seems this is going to be Sun's new direction for its in-house CPU design efforts. Furthermore, both Intel and IBM are working on other highly parallel processors and AMD is expected to eventually introduce a dual-core Opteron. So, will more threads prop up Sun's performance?"
Viagra? (Score:5, Interesting)
Seriously though, why did the author have to use the term Viagra to simple mean 'performance boost'?
Will more threads prop up Sun's performance? (Score:3, Interesting)
Of course this will be the direction Sun goes in. (Score:5, Interesting)
It's the same thing that's been happening for the last decade. As x86 slowly creeps in on Sun/IBM/Whatever's market, they have to come up with something "bigger".
Right now, the Opteron, with embedded memory controller and gobs of I/O, has really entered what was previously a niche market that Sun made very nice profits from.
So, now that particular cash-cow has fallen to the ravages of commodity parts, they're moving their sites even higher. Sun's never been the company to make $5 profit on each of 50 million computers, they'd much rather make $300,000 each on 1,000 computers.
steve
'taint no CPU advances going to help Sun now (Score:5, Interesting)
1. overall system performance of their partitionable systems (i.e. the ones people will pay a premium for over low-end systems where Linux on Intel/AMD is killing them) is severely hampered by their 150MHz (Mhz!) backplane. Sun views this as a plus because it allows customers to run boards with differenc CPU speeds (e.g. a 750MHz board (5x backplane speed) and a 900MHz board (6x backplane speed)). So, board to board thruput suffers and overall scalability is reduced.
2. Their desire for greater hardware isolation between domains, down to only a 2 or 4 CPU board with whatever memory happens to be installed on those boards, severely limits the flexibility in providing workload management between logical servers (domains), as well as less flexibility to create / deploy fewer, smaller servers. IBM's LPAR architecture, and HP's VPARs, are kicking Sun's ASS!
Multi-threading and selectable IO channels (Score:5, Interesting)
especially for server software that threads.
I'm especially intrigued on how this will
work with the Java NIO (new IO) libraries,
which handle pooled selectable IO channels.
Niagra and Java NIO together looks like
a really fast way to do mass serving...
Can anyone comment on threads sharing IO?
This could be HUGE (Score:5, Interesting)
But that's a big "if."
Re:Of course this will be the direction Sun goes i (Score:5, Interesting)
Sony, IBM, and Toshiba Have the Cell Processor (Score:4, Interesting)
The Cell processor follows the same design idea, if not more radical. Sony has cross licensed it to IBM and Toshiba. Toshiba is already planning on using Cell in high end processing.
The big question is if bandwidth constraints will choke these massively parallel superscalar processors.
Re:'taint no CPU advances going to help Sun now (Score:5, Interesting)
1. It is an easier upgrade path for customers. I think Sun learnt that it is easier to sell its customers incremental upgrades than to sell them brand new designs. Remember that the market they sell to (telco, financial) absolutely despises having to test all their mission-critical applications on new, unproven hardware. So while the slow backplane is a performance limitation, many customers may prefer stability to cutting-edge performance.
2. Wait for the 'Zones' in Solaris 10
Re:Memory subsystem? (Score:3, Interesting)
Re:Of course this will be the direction Sun goes i (Score:5, Interesting)
Re:Memory subsystem? (Score:5, Interesting)
1) Memory latency will be a bigger and bigger bottleneck in systems as cpu frequencies scale
2) Technology will not allow memory latency to keep pace with cpu frequency.
See ace's previous interview [aceshardware.com]
A snippet:
Chris Rijk [Ace's Hardware]: Stalled on waiting for data, basically.
Dr. Marc Tremblay: Yes. In large multiprocessor servers, waiting for data can easily take 500 cycles, especially in multi-GHz processors. So there are two strategies to be able to tolerate this latency or be able to do useful work. One of them is switching threads, so go to another thread and try to do useful work, and when that thread stalls and waits for memory then switch to another thread and so on. So that's kind of the traditional vertical multithreading approach. The other approach is if you truly want to speed up that one thread and want to achieve high single thread performance, well what we do is that we actually, under the hood, launch a hardware thread that while the processor is stalled and therefore not doing any useful work, that hardware thread keeps going down the code as fast as it can and tries to prefetch along the program path. Along the predicted execution path [it] will prefetch all the interesting data and by going along the predicted path [it] will prefetch all the interesting instructions as well.
Re:This could be HUGE (Score:2, Interesting)
Re:'taint no CPU advances going to help Sun now (Score:2, Interesting)
2. They HAD to come up with something to counter LPARs, etc... the market shifted and they got caught with their domain's down at their ankles... of course, no doubt IBM and HP could (and frankly, maybe have) come up with something akin to zones / containers as well, ON TOP OF h/w LPARs... the fact remains, better h/w flexibility
Re:'taint no CPU advances going to help Sun now (Score:5, Interesting)
2. As with all things, there are cost/benefits to every feature. I'm sure there are applications that are better suited with greater hardware independance. Still I'm not sure what you mean here, are you advocating more manageability between CPU's and different domains (which is good for managing severals VM's?)? With a processor that has eight cores, you'd assume that one would be able to put a vm on each one with that vm, having four hardware threads available. How is IBM/HP's offering different?
Re:Will more threads prop up Sun's performance? (Score:3, Interesting)
Not it won't. At least not so simply. It will see the benefits if there are enough concurrent threads running (as you said), and even that if these are not waiting for each other. So it will work for many clients at once.
I have my doubts that this architecture will help with most real world tasks - even real world server tasks - even with completely blown out of proportion threading like java seems to lead people to.
Let's face it, the reason Intel or IBM are not going into that direction that far are not that they couldn't if they wanted to.
It's more that they still have other tricks in their sleeves to ramp up their processor power, and Sun hasn't - or can't afford them.
For me this is the last desperate attempt from Sun to prolong their relevance in the processor arena.
Re:Of course this will be the direction Sun goes i (Score:5, Interesting)
This is not bigger. Taken to the extreme, this is like if Commodore was still in business and tried to sell computers with 2^32 6502 procs.
Look at the chart in the article to see how desperate Sun is:
They admit that existing Opterons Xeons not only kick the ass of their newest, existing architecture for a single thread, they also concede that even their not-existant future proc won't even be faster for single threaded apps.
Ok, you say, but it is faster for multithreaded apps. The only problem with that is that I bet that a recent multiproc Opteron/Xeon will give the future Sun architecture a run for its money.
And IBM/Intel won't have any problems building multicore procs, if they want. They just don't need to, at the moment.
IOW, looking at this chart one might ask himself why tSun even tries to build processors nowadays.
Re:Why Niagra will suck (Score:3, Interesting)
Re:'taint no CPU advances going to help Sun now (Score:4, Interesting)
If I understand the backplane as the CPU->CPU bus, then wouldn't a multi-core CPU reduce dependency on the backplane? For applications that require low latency and high throughput how can you get higher transfer rates that what's available on the CPU itself?
As per the second point: Wouldn't a multicore-multithread multi-CPU server offer more flexibility for load balancing and on-damand peak handling (ie, move CPU2 Cores 1-3 from mail/fileserver duties to httpd to handle slashdotting)?
It seems the differences you are stating are about the overhead of managing multiple physical CPUs, but with this new chip a 4 way could handle what a 16 or 32-way did before. Thus the intra-CPU differences between IBM/HP and Sun are fairly irrelevent. Maybe I'm missing your point.
That is not their market (Score:1, Interesting)
Yes and no (Score:1, Interesting)
Re:Why Niagra will suck (Score:3, Interesting)
Maybe an Oracle techie/insider can debunk these rumors coming from the sales droids.
1) 10g was made for linux, all other versions are a "port"
2) At Oracle you need Larry's signature on the PO if you want to order a Sun box.
If either of these rumors are true, that's pretty bad news for Sun.
Re:Will more threads prop up Sun's performance? (Score:4, Interesting)
An Interesting Plan (Score:3, Interesting)
It's ironic to see how positions have changed. Intel and AMD are developing multi-core CPUs for use in 4+ way systems, while Sun develops a CPU that is SMP incompatible. Of course Sun is also working on Rock, and hoping it can compete with a Xeon as a single cpu, while still scaling for 100 CPU Infernos (or whatever they are going to call them.)
Re:Of course this will be the direction Sun goes i (Score:3, Interesting)
The only way I can see them staying alive is to find a sucker to dump SPARC on and embrace Opteron. If they tie their future to AMD's then AMD might decide to keep their promises. I do not thing it would be very wise to make the same bet on intel. I'm not sure if Solaris has a future but I'm pretty sure that if SPARC does, it won't be Sun driving.
Re:Sun Sets By 2008 (Score:2, Interesting)
Firstly, Sun are absolutely right to keep hold of their processor technology. The market has long since grown up to the feeds-n-speeds contest, and realised that memory latency and I/O throughput matter right through the server room, not just on the top end systems. To throw away their ability to create a competitive advantage through innovative system architecture would be madness - we've seen how HP have squandered their high end server business through precisely that tack. The costs of system *and* processor R&D are very high, but are a key part of what makes Sun different from Dell.
Secondly, Sun have two major investments which are yet to start paying back: The JES/JDS stack is now at GA, and could become a massive source of recurring revenue over 2-3 years; the throughput computing technologies are further off, but again is a potentially disruptive technology. Are IBM and HP quietly working on their own versions? Well, HP aren't because they haven't got a processor architecture any more.
Thirdly, Sun won their lawsuit against Microsoft (out of court) though everyone is saying that they threw in the towel: they got more money out of Microsoft that any court settlement would have been, they got an undertaking from Microsoft to support standards, and they got a load of proprietary Microsoft API and protocols as a hostage in case they welch (this was a very clever deal).
So when will Sun stop losing money? Probably as large corporates and government departments/agencies approach their next Windows refresh and a proportion (doesn't need to be that big a proportion either) run with JES/JDS. That refresh cycle comes every 3-4 years, so while we have a few early adopters now, next year could be interesting as the Win2K refreshes start appearing. And Sun has enough cash in the bank (even before another $2bn from Microsoft) that there's no need to sacrifice the strategy.
D.