Sun Kills Rock CPU, Says NYT Report

BBCWatcher writes "Despite Oracle CEO Larry Ellison's recent statement that his company will continue Sun's hardware business, it won't be with Sun processors (and associated engineering jobs). The New York Times reports that Sun has canceled its long-delayed Rock processor, the next generation SPARC CPU. Instead, the Times says Sun/Oracle will have to rely on Fujitsu for SPARCs (and Intel otherwise). Unfortunately Fujitsu is decreasing its R&D budget and is unprofitable at present. Sun's cancellation of Rock comes just after Intel announced yet another delay for Tukwila, the next generation Itanium, now pushed to 2010. HP is the sole major Itanium vendor. Primary beneficiaries of this CPU turmoil: IBM and Intel's Nehalem X86 CPU business."

Comments

another one bites the dust! x86 uber alles!

[Anonymous Coward]

Yuck.

Some days I hate this industry.

RPS

[eldavojohn]

Sun Kills Rock CPU, Says NYT Report

Sun has instead moved on to develop the superior Paper CPU while critics argue about the hypothetical "Scissors CPU" that competitors may be secretly developing.

Re:RPS

[Ender_Stonebender]

You forgot the low-cost, low-power Lizard CPU (being developed by the designers of ARM CPUs) and the highly logical Spock CPU (from AMD, of course).

Re:RPS

[dkleinsc]

Actually, the real problem is that Rock CPU faced off with Guts CPU, Bomb CPU, Fire CPU, and Ice CPU, but hasn't been able to handle Cut CPU.

Re:RPS

[moderatorrater]

critics argue about the hypothetical "Scissors CPU" that competitors may be secretly developing

I've seen the supposed specs for the scissors cpu, and I can attest that rock would have absolutely crushed it.

Re:RPS

[Foodie]

Rock CPU couldn't compete with Paper CPU, so it was canned.

Re:RPS

[Bluesman]

Awesome. Mod parent up.

Re:RPS

[Hal_Porter]

<Sigh>

Re:RPS

[1stvamp]

Frankly I'm awaiting the Lizard revision..

Re:RPS

[Anonymous Coward]

Yes, but what kills Sun? Seems like a pretty unbalanced game of Rock, Paper, Scissors, Sun.

Re:RPS

[CarpetShark]

I think you'll find that any office supply company can provide scissors which beat Sun's CPUs.

Re:RPS

[Anonymous Coward]

Rock CPU, Paper CPU, Scissors CPU, Lizard CPU, Spock CPU - Note: I always choose Spock CPU when I play.

Re:RPS

[WhyDoYouWantToKnow]

Entropy

Re:RPS

[K. S. Kyosuke]

How is Entropy supposed to "balance" any game, when Entropy always wins in the end? ;-)

Actually it was crap

[Chrisq]

Actually it was crap. Not for nothing was it known as "The Turd Rock from the Sun"

That's just dynamite!

[davidwr]

*groan*

Re:That's just dynamite!

[bluesatin]

Zombies? On my Slashdot? It's more likely than you think.

Re:That's just dynamite!

[Anonymous Coward]

This is a bummer, I have 10 5220s in a datacenter space that cost over time more than the servers. If I can get these down to 5 with 16 core. Life would be great. BTW the T2 Proc rocks when you compile apps using -fast flags. One the fastest 2U boxes ever.

Re:Very Interesting...

[AdmiralXyz]

You may want to check your internet connection, I think your post has ended up in an alternate-universe Slashdot. How's the economy over there?

Re:Very Interesting...

[Anonymous Coward]

Sun is in the process of being purchased by Oracle, retard.

IBM bought Sun?

[characterZer0]

Oracle is gonna be pissed.

Sun kills rock!

[Drakkenmensch]

... but paper beats rock... and scissors beats paper! Kiff, we have a conundrum!

Re:Sun kills rock!

[Theoboley]

Sun Burns paper, melts plastic handle on scissors and apparently kills rock.

I, for one, welcome our bright, warm overlord.

Re:Sun kills rock!

[Bluesman]

Uggggh.

Re:Sun kills rock!

[Drakkenmensch]

Kiff, get ready to take blame for this! In three, two, one... *points*

Sun kills Rock?

[SailorSpork]

Wait, so if sun kills rock, sun burns paper, and sun melts scissors... SUN IS INVINCIBLE!

Re:Sun kills Rock?

[haruchai]

That's the most insightful post yet in this thread. Unfortunately, it's not true where SUNW is concerned.

Re:Sun kills Rock?

[Chris Burke]

Just as paper covers rock, Burns covers sun!

Re:Very Interesting...

[Anonymous Coward]

You're confused. Sun was purchased by Oracle. IBM withdrew their bid.

Um, Opteron?

[tjstork]

Not that I am an AMD fanboy, but, my dual opteron PC just ordered me to remind you all that AMD will also benefit from this choice. Indeed, Sun already uses AMD Opteron parts for some of its servers....

Re:Um, Opteron?

[Bigby]

Maybe with the loss of some of the hardware Sun produced, Oracle will purchase AMD

Re:Um, Opteron?

[vil3nr0b]

There is no price/performance contest in comparing AMD Phenom Sexcore processors versus competitors. You could build a whole system around DDR3/i7 architecture, but it is unaffordable in large clusters. BTW, I am an AMD fanboy, especially after upgrading a cluster to the new Phenom chips. It was able to work perfect with DDR2 and saved a fortune just upgrading CPU's to get about a 15 percent performance increase. This only helps AMD.

Re:Um, Opteron?

[diegocgteleline.es]

They also use Intel (in fact, IMO they seem to like more their intel partnership, probably due to the fact that AMD these days suck). So I don't see how this would benefit AMD alone...

Re:Um, Opteron?

[fm6]

True. But Sun also make Nehalem servers. And lately Nehalem has been getting a lot more interest.

Re:Um, Opteron?

[afidel]

Hahaha, Nehalem is the cheapest virtualization platform by a LARGE margin. The ability to do greater than 2 DIMM's per core is huge. Unless you are talking about HPC in which case the balance of performance, price, memory and power usage also generally comes out in favor of Nehalem.

Re:Um, Opteron?

[robthebloke]

To be fair the parent did say he'd just saved a fortune upgrading a cluster by going AMD. Sure, if you are starting from nothing, Nehalem may be the best bet. If however you already have a tonne of DDR2 & AM2 motherboards, then the AMD route is going to be far cheaper...

Re:Very Interesting...

[patch0]

"Despite Oracle CEO Larry Ellison's recent statement that his company will continue Sun's hardware business"

More likely reason

[downix]

It is more likely that Sun compared the Rock to Fuji's new SPARC CPU and realized that it could not compare for the price/performance. Frankly, looking at the two, Sun made the wise move, killed off a weaker chip, and will likely push forward the SPARC64 VVIfx, which is further along in development and will be ready sooner.

Re:More likely reason

[the donner party]

The Fujitsu SPARC64 VIIfx does look interesting, but does anyone know when it is actually supposed to be released?

Re:More likely reason

[TheRaven64]

The Rock is an amazing chip on paper. It runs an extra fetch/decode part of the pipeline a few cycles ahead so that it is always loading the needed data into the cache before it's needed.

If this technology doesn't work, however, Rock is a pretty unimpressive chip and there is no evidence that it does actually work (for example, it doesn't predict across computed jumps, which accounts for a lot of cache misses in current chips). Even if it does work, Rock looked like it would perform best on the kind of workloads where the T2 does well, but probably not as well as the T2. Out of the SPARC64 series, Rock, and the T2 and successors, Rock is by far the weakest. The SPARC64 does well on traditional workloads, the T2 on heavily-parallel workloads. Between the two, Sun already has processors for pretty much any market they want to be in - Rock just doesn't fit commercially. Note that the summary's comment, there is no indication that they are killing off the Niagara line - they aren't exiting the CPU business, just killing one failed experiment. Not the first, and probably not the last, time Sun has killed off an almost-finished CPU because there was no market for it.

Re:More likely reason

[Comatose51]

Assuming what you say is correct, we still have to wonder why did they start the project in the first place if there was no market for it? Perhaps that's why Sun is in such big trouble? A lot of my fellow engineers are amazed by Sun's technology but can't figure out why they're in such bad financial state. This could explain it.

Re:More likely reason

[TheRaven64]

I was at a talk by a former Intel chief architect a while ago which explained this. It takes an absolute minimum of about five years to get a new CPU to market. When you start, you have to make guesses about the kind of workload people will be running, their power and financial budgets, and the process technology that will be available to you for producing it. Once you've made these guesses, you can generally come up with a chip that meets the requirements.

The Pentium 4 is the canonical example of a chip made with bad guesses. The P4 team were told to make it fast at all speed. They missed the market, because they didn't notice that people were starting to care about power consumption, and few people wanted a 120W CPU - especially not in the data centre where the margins are high, but power and cooling are expensive. They also made some bad guesses about process technology, thinking that the process guys would fix the leakage problem so they could ramp the clock speeds up to 10GHz. They came up with a design that scaled up to 10GHz, but needed a process technology that still doesn't quite exist to produce it at these speeds.

I suspect something similar happened with Sun. First, they made some bad guesses about how well the thread scout would work. It's a nice idea on paper, but doesn't seem to perform well. The result is that Rock will perform better than other approaches on highly-deterministic CPU-bound workloads with lots of threads, while in the real world highly-parallel workloads tend to be I/O bound or have less predictable code flow.

The T2 goes in completely the opposite direction. It contains a set of very simple cores. They omit most of the complex logic found in other processors, and instead just have a lot of execution engines. If you have a workload that contains a lot of I/O-bound threads, then the T2 gives insanely good performance (both per Watt and per dollar). Sun began designing this family of chips right at the peak of the .com boom, and they are perfectly suited to web-serving workloads (they also do well on a lot of database workloads, which is one of the reasons Oracle is interested in them).

One of the things Sun does very well is recycle technology. There are a lot of half-dead projects at Sun that are not commercially exploited, but have fed ideas into their other products. Even though Rock is dead, I wouldn't be surprised to see some of their ideas appear in the T3 or T4. The hardware scout is only useful on a few workloads, but it's relatively easy to implement on something like the T2, so we may see it reappear in a future design.

Re:More likely reason

[drinkypoo]

The Pentium 4 is the canonical example of a chip made with bad guesses. The P4 team were told to make it fast at all speed. They missed the market, because they didn't notice that people were starting to care about power consumption

There are a number of problems with your analysis, not least that the Pentium III is faster clock-for-clock than the Pentium IV at almost all workloads; its failing was that it did not scale, but it begat the Pentium M and to some degree, the Core architecture. Sun has been wildly flailing its arms about trying to come up with an architecture worth carrying into the future. So far, no dice. This is just more of the same. Totally canning two architectures ought to be the end of Sun's attempts to make new SPARC processors; for the love of all that is holy, leave it to Fujitsu. Help them, if you must. It can only set them back so far...

Re:More likely reason

[hairyfeet]

Well, I can tell you as someone who has been building and selling PC since the days of Win3.xx why I think the P4 bombed, and it is because of this line I got from customers quite often-"I like this PC, it is fast and all, but it sounds like a jet engine taking off. Is there any way to make it quieter?"

And of course the answer was no. Because short of going liquid cooling, which was crazy money at the time and still isn't cheap, the P4s with their high TDP needed some serious fans to keep that sucker from melting down. I have a Cedar Mill P4 3.6Ghz box that I'm refurbing tonight for my oldest, and while not as seriously noisy as the Prescott, she is still pretty damned loud when compared to my AMD dual.

So while the P4 wasn't a bad arch IMHO, and the Celeron P4s made great boxes for teens and granny, most folks have a little quiet "computer room" where they do everything computer related here and having a P4 jet engine in that little room was seriously irritating. I've been building my customers AMD and Pentium Dual Core based machines to replace their aging P4s and all I hear from them is how fast and yet how quiet they are. Some have even expressed concern about overheating because the P4 conditioned them to believe a fast PC is a noisy one.

Re:More likely reason

[Anonymous Coward]

I decided to post anon as I worked at Sun during the tail end of Cheetah and the beginning of Rock.

Rock (aka Turd Rock from the Sun) was not the first turd from Sun. The last one was USIII (Cheetah). What happened there is that it got delayed and by then the L2 cache it had been designed for was not sufficiently larger than the competition's (I think the original idea was 1 or 2 MB configs), so the option was added to add really big L2 caches. One of the pie in the sky ideas early on was putting the L2 tags on the die for speed. So by then there was no room for more tags. You ended-up having a 512 byte L2 cache line size if I recall correctly if you had 8MB of L2 cache. Plus since when it was designed they addressed the problem of waiting around for a cache line to fill by making a special purpose wide fast bus for it they did not have much sectoring. There was either no sectors or only two, I cannot remember (by USIIIi all this broken L2 cache desing was rectified so I am fuzzy on when what was when). So say there were two. What would happen on a cache miss is that the 256 byte sector that needed would fill. when it was done, the instruction stream would continue (no amount of reordering would prevent a pipeline stall for filling 256 bytes) and the other sector would start filling. Now imagine that cache miss was for data. How often do you look at data structures that are 512 bytes big (common random access case)? Turns-out 64 bytes is a good real world figure that is ideal 95% of the time. Just think about how much memory bandwidth and time is being wasted. Now imagine that cache miss was for an instruction. 512 bytes is 16 instructions. Again in 95% of code there is a branch in less than 16 instructions.

So you might think how can something like this happen. The reason is that the the hardware people were their own kingdom, and the US people a fiefdom within. They #1 did not think like software engineers and came-up with pie in the sky ideas (like that L2 cache) which led to delays (another thing they could have done is made L1 caches that were physically tagged, but that is okay Sun engineers had been dealing with coloring for years already) and #2 did not simulate early on enough. When they did run simulations they had everything already worked-out on paper for up to 2MB L2 and things were good. Then they just did tweaks and did not run simulations again until much too late. The simulations showed that for almost all cases USIII was slower with 8MB L2 cache than with 2MB, think about that.

Rock was more of the same. In fact the simulation was done even later. The pie in the sky idea was the leap frogging prefetcher(they called it a hw scout). When they ran simulations after doing a bunch of work on it, they saw that the way typical code branched it was not all that good for the added memory bandwidth consumption. So they added a few tweaks to that, but it was hopeless. So they needed something else to make the chip worthwhile, transactional memory. Did they do it ala PPC et all with reservations on cache line boundaries, no they came up with a scheme with two new instructions and a status register. You did a chkpt instruction with a pc relative fail addr to jump to in case something was not guaranteed to be atomic. At the end you did the commit instruction. If something got in the way before everything got out the write buffer, you would arrive at the fail addr where you could check the cps register for info and nothing was committed. Can anyone else see how difficult this would be to get right? They were hardware guys and they did not see how hard of a problem it was? In fact the implementation they had had conditions like if an interrupt occurred or if you did a divide instruction you would end-up at the fail addr (yes if the other core on the die did it as well). My hunch is that the complexities of this transactional memory scheme is what delayed Rock for more than 2 years.

Another example was Jaguar USIV. For that one they decided that they could have less frequent pipe line stalls i

Re:More likely reason

[petermgreen]

There are a number of problems with your analysis, not least that the Pentium III is faster clock-for-clock than the Pentium IV at almost all workloads;
It is but IIRC intel throught at the time that they would be able to push the P4 to crazy clock speeds which would more than make up for the lower performance per clock.

Unfortunately they didn't get the clock speeds they had hoped for and the high clock speeds they did get required very high power consuption.

Re:More likely reason

[Anonymous Coward]

There are a number of problems with your analysis, not least that the Pentium III is faster clock-for-clock than the Pentium IV at almost all workloads; its failing was that it did not scale, but it begat the Pentium M and to some degree, the Core architecture.

How is that a problem with his analysis?

The Pentium 4 was designed to achieve high performance by having really high clocks to compensate for its poor per-cycle efficiency. It hit 3.8 GHz in late 2004, on a 90nm process. 4.5 years later, on 45nm, we still don't have any current processor design which clocks that fast (outside of overclocking, but then again P4 still overclocks higher than any current production processor -- IIRC people have gotten them over 8 GHz on liquid nitrogen).

The P3 basic design could have scaled if Intel was trying to, which they weren't. It did scale when they turned back to it. The reason why they went back was that (as the GP post said) P4 turned out to not scale as well as intended.

The P4 achieved high frequencies by using very fast (=high power) logic transistors and lots of pipeline stages. Lots of stages adds a lot more transistors, not just for the extra latches but also due to complicating many parts of the processor (for example, more stages requires the OoO engine to track more in-flight instructions). But the P4's architects didn't anticipate a severe problem which cropped up after the P4 hit the market. P4 was originally targeted at the 180nm process node, where there were only hints of the problem that would dominate the entire semiconductor industry at 130nm, 90nm, and 65nm: leakage current. As transistor gate insulators got thinner, it proved impossible to prevent significant leakage current; where once a CMOS logic gate would only draw power when it switched, half or more of the power of an operating CPU became constant leakage current through the gates. (Intel has finally solved this at the 45nm node with their HKMG process, which changes the materials used for gates and gate insulators.)

It turns out that high power transistors have worse leakage than transistors tuned for low power, and of course the P4 design had lots of them. Intel was forced to limit the P4's potential for clock scaling just to keep power down to relatively reasonable levels. (In absolute terms, P4 was still very hot -- it would have been a total dog if they didn't push it to the edge of what was possible to cool in a desktop computer.)

The P4 was intended to scale to 10 GHz and beyond during its lifetime. And it possibly could have -- in an alternate universe where the leakage current problem didn't exist.

Re:More likely reason

[Chris Burke]

There are a number of problems with your analysis, not least that the Pentium III is faster clock-for-clock than the Pentium IV at almost all workloads; its failing was that it did not scale

Performance = Instructions Per Cycle * Cycles Per Second. Yes the P4 had lower IPC than the P3, but yes it did in fact scale very well with frequency. Both in the sense that it's highly pipelined design allowed for higher clock frequencies, but also in that IPC didn't drop off as fast with increased frequency as it did with the P3. The first P4s (especially when paired with SDRAM) were slower than P3s because the clock frequencies were very similar. But the P4's frequency rose much faster than the P3 could have, and with subsequent revs fixing some of the biggest IPC problems it got good performance. So yeah, it did scale -- at least until leakage current bit them in the ass. That and the changing market doomed the P4, but yes it scaled.

but it begat the Pentium M and to some degree, the Core architecture.

Not really. The Pentium M is a direct architectural descendant of the P3, which is itself a descendant of the PPro. The Core is a modified Pentium M, and Core 2 an updated Core. The only aspect of the P4 that survived is in the ISA, which really doesn't have anything to do with the microarchitecture (though the P4 being highly suited to streaming may have inspired development of SSE2/3).

So yeah. The P4 was a gamble that at first looked like it would pay off, but ultimately Intel would have been better off having never made it and moving directly to further enhanced PPro-derived architectures.

Re:More likely reason

[Anonymous Coward]

The one good example was Niagra. It seems that for that one somebody must have dropped H&P and it opened to the page describing how a T1 like processor was inevitable. There were no pie in the sky ideas (others had done real not research cpus with similar ideas like barrel threading and HT). Somehow the ON people got their hooks into that project early on and in particular there was a concerted effort at simulation before any difficult to back away from design was done. Also the whole push to make it an open spec came from them. The whole Sun Labs pie in the sky thinking was avoided (by avoiding certain people largely). That was a success.

Eh. I only count it as a mild success. The T1 had at least one really bad idea (sharing a single low peformance FPU between multiple cores). And the T2, which fixed that, is not very competitive outside a very narrow niche: it sells mostly to people who (A) cannot migrate off SPARC, (B) have workloads which can keep ~64 threads fully loaded, and (C) can live with the extremely low performance each individual thread experiences (i.e. they're OK with high throughput at the cost of poor latency). If any of these things are not true, there are much better choices than T2 available.

Re:More likely reason

[raftpeople]

Correction:
"It hit 3.8 GHz in late 2004, on a 90nm process. 4.5 years later, on 45nm, we still don't have any current processor design which clocks that fast"

2007 Power6 ships at 4.7ghz
2008 Power6 ships at 5.0ghz

Re:More likely reason

[drinkypoo]

Performance = Instructions Per Cycle * Cycles Per Second. Yes the P4 had lower IPC than the P3, but yes it did in fact scale very well with frequency. [...] So yeah, it did scale -- at least until leakage current bit them in the ass. That and the changing market doomed the P4, but yes it scaled.

A big part of what was wrong with the P4 was that it had a super-long pipeline and the price for branch misprediction was gigantic. Higher-clock rate parts actually had longer pipelines with more stages which were there just to add latency. And the leakage current did indeed "bit[e] them in the ass", so P4 did not scale. The huge pipeline was a symptom of a bigger problem, though, which was that the P4 is a big pile of crap. An elegantly designed processor doesn't need egregious numbers of wait states in the pipeline (Intel called them "DRIVE" in the P4) because functional units are closed together and there's a logical flow to the physical design of the processor... that the P4 lacks.

The high clock rate Pentium 4 processors were designed to get high benchmark scores, plain and simple. They provided seriously diminishing returns, not least because of their anemic memory bandwidth as compared to the competition. If the P4 had been so wonderful then the Core would have been based on it instead of essentially being based on the P3.

Re:More likely reason

[Chris Burke]

I guess I should just say this first: I'm no fan of the P4 architecture, to be frank I always thought it was stupid, and driven by marketing. It was a big mistake on Intel's part that cost them heavily (as I alluded to last post when I said they would have been better off if they had skipped it entirely). But not all the facts about the P4 are negative, and what I feel are matters of history at this point should be fairly represented to give Intel engineers credit where credit is due.

A big part of what was wrong with the P4 was that it had a super-long pipeline and the price for branch misprediction was gigantic.

Indeed. This was the basic problem with the architecture, the Achilles's heel as it were. Though to make up for this it had basically the best branch predictor in the industry at the time. Nevertheless, code with hard to predict branches was not its friend.

Higher-clock rate parts actually had longer pipelines with more stages which were there just to add latency.

Yes, the pipe stages kept increasing, which I thought was ridiculous, but not all of it was there just to reduce cycle time, a lot of it was there to add additional logic that boosted the IPC. From Willamette to Northrwood, Intel made a lot of improvements to the architecture. Based on the frequency scaling in 180 and 130nm and projections to future generations they had a very compelling argument that this architecture had a lot of headroom in terms of increasing clock stages to increase frequency with marginal loss in IPC, such that the curve, despite having diminishing returns, looked very good out through around 20GHz parts.

The Northwood core was quite solid, and performed well against AMD on most things, while dominating on streaming-related things (which obviously it was designed well for, and Intel could leverage the ISA to help with).

And the leakage current did indeed "bit[e] them in the ass", so P4 did not scale.

It was a scalable architecture was my point, but yes, the reality of device physics trumps the world of pure boolean logic. The thing is, I don't think anyone was expecting to hit the leakage wall at 90nm like everyone did. I think the best projections everyone had been making were wrong -- and Intel had the best process and process engineers. The increasing parasitic capacitance was what everyone was worried about as they delved deeper into sub-micron technologies, they thought that RC delay constants were going to be limiting processor growth -- Intel took this into account in their projections, btw. RC delay went up, but not like leakage did where it went from 1-10% to 30-50% of the power. IBM and AMD both seemed to be caught off guard by it too, to a lesser degree though because they weren't betting as much on frequency scaling.

Nevertheless, Prescott was actually a pretty good part, performance wise... if you were willing to accept it being not-so-good in terms of sucking juice, sounding like a jet engine, and counteracting your air-conditioner. Sure it pushed the envelope of how much current you could pull from a standard outlet, but was that really more outrageous than using liquid (nitrogen?) cooling? Oh, right, yes it was, because while both are expensive, the liquid cooling solution results in something quiet and not susceptible to poor room ventilation.

because functional units are closed together and there's a logical flow to the physical design of the processor... that the P4 lacks.

The P4 pipeline was quite logical and flowed well imo. It was pretty much necessary to get the clockspeeds they did. Very direct paths from the L2 through decode into the trace cache, to the branch predictor and dispatch, schedulers with fixed-latency replay paths for things like l1dc misses tuned to l2 latency in order to make a lot of decisions simpler.

The high clock rate Pentium 4 processors were designed to get high benchmark scores, plain and simple.

More to the point -- the Pentium 4 was mandated by marketin

Re:More likely reason

[Anonymous Coward]

In addition, the IBM System z10 EC processor, which started shipping in early 2008, is clocked at 4.4 GHz. It is currently the highest clock speed CPU with more than two cores per chip. (It is quad-core.)

Re:More likely reason

[Anonymous Coward]

I decided to post anon as I worked at Sun during the tail end of Cheetah and the beginning of Rock.

Rock (aka Turd Rock from the Sun) was not the first turd from Sun. The last one was USIII (Cheetah). What happened there is that it got delayed and by then the L2 cache it had been designed for was not sufficiently larger than the competition's (I think the original idea was 1 or 2 MB configs), so the option was added to add really big L2 caches. One of the pie in the sky ideas early on was putting the L2 tags on the die for speed. So by then there was no room for more tags. You ended-up having a 512 byte L2 cache line size if I recall correctly if you had 8MB of L2 cache. Plus since when it was designed they addressed the problem of waiting around for a cache line to fill by making a special purpose wide fast bus for it they did not have much sectoring. There was either no sectors or only two, I cannot remember (by USIIIi all this broken L2 cache desing was rectified so I am fuzzy on when what was when). So say there were two. What would happen on a cache miss is that the 256 byte sector that needed would fill. when it was done, the instruction stream would continue (no amount of reordering would prevent a pipeline stall for filling 256 bytes) and the other sector would start filling. Now imagine that cache miss was for data. How often do you look at data structures that are 512 bytes big (common random access case)? Turns-out 64 bytes is a good real world figure that is ideal 95% of the time. Just think about how much memory bandwidth and time is being wasted. Now imagine that cache miss was for an instruction. 512 bytes is 16 instructions. Again in 95% of code there is a branch in less than 16 instructions.

So you might think how can something like this happen. The reason is that the the hardware people were their own kingdom, and the US people a fiefdom within. They #1 did not think like software engineers and came-up with pie in the sky ideas (like that L2 cache) which led to delays (another thing they could have done is made L1 caches that were physically tagged, but that is okay Sun engineers had been dealing with coloring for years already) and #2 did not simulate early on enough. When they did run simulations they had everything already worked-out on paper for up to 2MB L2 and things were good. Then they just did tweaks and did not run simulations again until much too late. The simulations showed that for almost all cases USIII was slower with 8MB L2 cache than with 2MB, think about that.

Rock was more of the same. In fact the simulation was done even later. The pie in the sky idea was the leap frogging prefetcher(they called it a hw scout). When they ran simulations after doing a bunch of work on it, they saw that the way typical code branched it was not all that good for the added memory bandwidth consumption. So they added a few tweaks to that, but it was hopeless. So they needed something else to make the chip worthwhile, transactional memory. Did they do it ala PPC et all with reservations on cache line boundaries, no they came up with a scheme with two new instructions and a status register. You did a chkpt instruction with a pc relative fail addr to jump to in case something was not guaranteed to be atomic. At the end you did the commit instruction. If something got in the way before everything got out the write buffer, you would arrive at the fail addr where you could check the cps register for info and nothing was committed. Can anyone else see how difficult this would be to get right? They were hardware guys and they did not see how hard of a problem it was? In fact the implementation they had had conditions like if an interrupt occurred or if you did a divide instruction you would end-up at the fail addr (yes if the other core on the die did it as well). My hunch is that the complexities of this transactional memory scheme is what delayed Rock for more than 2 years.

Another example was Jaguar USIV. For that one they decided that they could have less frequ

Re:More likely reason

[Anonymous Coward]

Exactly!
I hope Oracle makes Sun profitable. I do not see T1 or T2 adv on TV or in newspapers. Not a lot people knows about them. BTW HP-ORACLE and Intel adv is almost in every Wall Street Journal newspaper (on the first page).

Re:More likely reason

[Anonymous Coward]

You are correct, sir. Complete brainfart on my part. I was thinking only about x86 processors.

Re:Very Interesting...

[Agronomist Cowherd]

Yeah, I'm sure IBM's purchase of Sun had a HUGE amount to do with this. Those IBM bastards, canceling competing projects left and right. I'm sure this was their secret plan all along. Killing SPARC because it's such a good competitor to Power and xSeries.

Oh wait, IBM DIDN'T purchase Sun. Oracle purchased Sun. The summary hinted as much.

You're really out of date. At least have a fact to add to your conspiracy theory. One fact is a big help.

Idiot.

Wow, there's not much left then.

[seeker_1us]

According to the CNET article, Tukwilla is pushed until 2010, and it's going to be 65nm instead of 45 nm. Since Intel has already demonstrated 32nm chips, that means Tukwilla will already be at least two generations behind when it's released. No new chip designs from Sun and Fujitsu decreasing the R&D budget. Sounds like this market is falling behind.

Re:Wow, there's not much left then.

[Funk_dat69]

Well there's IBM. And they don't seem to be slowing down:

POWER 6

POWER 7

also:

http://www.theregister.co.uk/2008/07/11/ibm_power7_ncsa/

POWER 7 sounds like crazy town...

Re:Wow, there's not much left then.

[Anonymous Coward]

POWER 7 sounds like crazy town...

That's a great code name for a CPU!

Re:Wow, there's not much left then.

[raftpeople]

I don't think Itanium being pushed out is a sign of anything other than that Intel would probably like to just kill Itanium and put all resources in x86 as they are creating very impressive procs lately.

Re:Wow, there's not much left then.

[Anonymous Coward]

Tukwila: a low-budget, low-end town whose claims to fame are Southcenter Mall, an Embassy Suites, TWO Marriott Courtyards, a Macy's furniture clearance warehouse and one of the most dangerous bus stops (at the mall on the edge of the parking lot) in King County outside of Seattle. Heck of a name for a high-end chip.

Re:Wow, there's not much left then.

[Anonymous Coward]

My god. If Power6 is anything to go on, this will be a total beast.

I remember way back I saw some rendering benchmarks between a 4ghz single core Power6, and a 2ghz Core 2 Duo. The Power6 was four times faster.

Re:Wow, there's not much left then.

[Anonymous Coward]

Are you sure? All Power6 CPUs are dual-core..

Re:Wow, there's not much left then.

[Anonymous Coward]

What do those POWER CPUs cost? $10k? more?

dom

Re:Wow, there's not much left then.

[Anonymous Coward]

Are you sure? All Power6 CPUs are dual-core..

IBM sells the "HPC Feature", the ability to turn off the other core on the chip (or indeed all the 7 other cores on the MCM), giving one single core access to the 32 MB (or 128 MB) of L3. This is useful for markedly single-threaded tasks with huge data or code sets. They of course leverage this for every suitable benchmark...

Re:Wow, there's not much left then.

[robthebloke]

The Power Glove would be a better name.

It doesn't really benefit IBM

[mzito]

Mostly, it just benefits Intel and AMD. Sun loses their high-end chip, which theoretically hurts their high-end offerings, but their high-end servers are an rapidly declining piece of their revenue. I've thought that Sun should drop SPARC entirely, except for supporting legacy customers. The niagara chip is an interesting concept, but most people today just want Intel/AMD chips in their servers.

Re:It doesn't really benefit IBM

[downix]

People want more viruses? As a virus is targeted at an architecture and api, and if you combine into a single chain, you wind up with a perfect storm for virus spreading. Witness the Irish Potato Famine.

I say we need more diversity of architectures, OS's, platforms and API's to prevent a Pandemic of computer malware. I still laugh at the memory of witnessing conficker trying desperately to install itself on my SPARC Kubuntu machine.

Re:It doesn't really benefit IBM

[mzito]

By your own example, though, clearly the current level of diversity hasn't helped mitigate the spread of malware, since conficker was able to install on many many PCs.

Then, if we decided we needed more diversity, how many more? I can't see having 10 major OSes making a difference, perhaps 50 with wide distribution.

So now, businesses, software developers, hardware manufacturers, tech support organizations have to support 50 different operating systems? Where's the ROI on that? How will we hire enough people who are trained on that many different configurations?

Certainly, we all want better computer security, but improving security by increasing IT complexity is like permanently banning travel between countries because of the fear someone might bring a disease in. It solves the problem, but damages everyone every other way.

Re:It doesn't really benefit IBM

[John Betonschaar]

Discounting x86 for big-iron server systems because they would otherwise attract viruses -much like the potato famine- is ridiculous. I think you're paranoia.

Re:It doesn't really benefit IBM

[peppepz]

In fiscal year 2008, Sun sold 4,532 $ millions in SPARC servers, and only 707 millions in x64 servers (source).
I don’t think it would have been wise for them to kill their biggest-selling product.

Re:It doesn't really benefit IBM

[confused one]

Actually it does benefit IBM. It's another piece of information their sales force can use in their campaign to convert Sun customers to IBM, whether it be on Power or on x86-64.

Re:It doesn't really benefit IBM

[davecb]

Rock is the high-clock-speed chip, while the Ultra VII and future variants are the high-end chips, which are absolutely necessary for things like the transaction processing loads of an eBay, much less a bank or large retailer.

--dave

Re:It doesn't really benefit IBM

[greed]

Just because they don't make the CPU doesn't mean they can't continue to make SPARC systems. They'll just be Fujitsu SPARCs. And maybe having one company doing SPARC will bring Fujitsu back to profit in that division.

Apple, Dell and Compaq are doing alright selling systems with someone else's CPUs in them.

Frankly, for general-purpose computing, I've never been impressed with SPARCs, and the "64 virtual core" Niagara thing is just useless; so I'm going to do a happy-dance if I can be shut of doing Solaris SPARC support. But it's not going to be in the next few years.

Re:It doesn't really benefit IBM

[SEE]

Sun's hardware is hardly Oracle's biggest-selling product.

And, remember, Ellison explained the purchase of Sun entirely in terms of Sun's software (Java and Solaris), making no reference to its hardware.

Re:It doesn't really benefit IBM

[Anonymous Coward]

Well I think you're stupidity.

Tukwila?

[Anonymous Coward]

> Intel announced yet another delay for Tukwila

Please tell me that's not an actual product name. (apologies)

Utter nonsense

[Nobo]

Nonsense. Everyone knows that paper kills rock.

Re:Utter nonsense

[jgostling]

Which is why they wrote it in a memo.

To summarise the article:

[GreenTech11]

To summarise the /. summary article, all computing hardware companies are going bankrupt, with the exception of Intel, who are delaying projects as well.

How I love this industry

Re:To summarise the article:

[Vengeful weenie]

Boom & bust baby.

I'm sorry, what?

[kurtmckee]

Intel announced yet another delay for Tukwila, the next generation Itanium

Please tell me that's not an actual product name. (apologies)

Re:Very Interesting...

[rodrigoandrade]

Then Sun should give them negative feedback and move on.

What are these architectures good for...

[astonish]

I'm totally ignorant of the sun/enterprise space of computing hardware. What are these architectures good at that x64/GPGPU aren't going to cover? I've seen in my own career things like SGI Oynx and even high-end rendering cards go to the wayside in favor of standard COTS hardware that is more agile, refreshes more frequently and is blazing fast...

What keeps this SPARC space alive?

Re:What are these architectures good for...

[downix]

Scale. x86 cannot scale up anywhere near as far as SPARC (or even MIPS for that matter) can. You realize that the cheapest SPARC can handle more threads per cycle than a dual-quad Xeon, and do it while using less electricity, right? As for the big-iron chips, they handle databases on a scale that dwarfs the address range of x86, relying on more registers than even exists in the x86 architecture.

Re:What are these architectures good for...

[Anonymous Coward]

Some people believe that for a truly stable and robust database infrastructure, enterprise grade, you cannot use anything other than SPARC/Solaris and Oracle. I don't necessarily believe this, but if it is good enough for Microsoft then it is good enough for me and my infrastructure.

Re:What are these architectures good for...

[Macka]

What keeps this SPARC space alive?

Same as with all proprietary high end solutions: customer ignorance. The customer goes to the vendors and says: "Here's my shopping list of business requirements. Please bid a solution that meets those needs". The vendor salesman (after wiping the drool from his/her chin) comes back with an Enterprise Class solution using propietary high end kit at the highest price the saleman thinks he/she can get away with to win the bid but beat off the competition. The whole thing is wrapped up in smoke and mirrors to make the customer feel valued and special with the assurance that they're getting the best in class. The whole thing is topped off with generous dollop of FUD dissing any other vendor solution. Things like: "The x86 space is too aggressive and its 3 year turnover cycle is bad for your business. Use our systems which have a 5 year life cycle and get a better return on your investment". Or here's another one: "Our chips are built with advanced RAS features. They're [self healing] and crash less often than x86". Oh and lets not forget that to buy one of their enterprise solutions, you usually also have to buy their proprietary enterprise OS and pay their enterprise software license fees at their inflated enterprise prices.

Perhaps you think I'm joking !

Re:What are these architectures good for...

[Anonymous Coward]

Then there are those who work in professional shops and realize that for scalable database infrastructure, enterprise grade, you can't beat...the boring old IBM mainframe, which amazingly doesn't seem to use Sun chipsets at all.

Re:What are these architectures good for...

[John Betonschaar]

Yes, and all these threads you get have access to crappy fpu's and horrible memory bandwith.

It's true that you can easily slap a lot of Sparc CPU's into a single machine than you can do so with x86, but since you're actually going to need all those CPU's to match even an off-the-shelf dual quad-core Opteron system for most tasks, the end result is that you're still spending much, much more money and probably suck more power too. For tasks that cannot be parallelized or executed concurrently Sparc is rubbish in every aspect imaginable.

I work at one of those companies that got lured into standardizing on Sparc hardware years ago, and now we're kind of stuck on it because we have all those systems in the field, with customers. A while ago we investigated upgrading to newer Sparc hardware (M3000) and we leased a test system to assess it's performance. For compationally intensive (FPU) tasks running 8-threads, the ~$11,000 Sparc64 IV with 8 cores / 16 hardware threads was about as fast as a $400 Core 2 Duo laptop. I'm not kidding....

So unless you want to run an enterprise database that has to handle 1000s of requests a second, Sparc has zero added value. If you really need a Sparc system for high-load, high-availability server tasks, I don't know. I'd guess a Power6 server or a rack of Opterons or Xeons wouldn't do much worse.

Re:What are these architectures good for...

[Funk_dat69]

I totally agree with you!

Now excuse me while I go pitch a Windows ME + celery + mySQL solution to eBay and give them the 'real' facts.

Re:What are these architectures good for...

[afabbro]

What you say is often, but not exclusively, true. The main reason people buy SPARC:

• The CoolThreads servers are genuinely different than others. Radically low power consumption and a bajillion threads. That doesn't mean they're good for everything, but in the app space they're marketed for, they're exceptional.
• If I have millions of lines of code written for Solaris on SPARC, I might want to run SPARC. Sun has a large presence in many markets and compatibility (left over from the days when x86 was nowhere near SPARC) is important.
• Above a certain level, x86 can't compete. You can say "yet" if you want. Sun, IBM, etc.'s high-end gear is the closest you can get to a mainframe, in terms of RAIDed memory (one bad chip doesn't bring down the system), hot-swapping CPUs, hardware partitioning, etc. There are a lot of people in love with clustered x86 boxes, but they do not scale as well. A single box with 32 CPUs will perform better than 16 boxes with 2 CPUs, every single time. The 16x2 might be cheaper, but there are a lot of apps that don't run as well that way. To take a very common example, Oracle RAC scales about as well as anything on "wide and small commodity," but Oracle certainly runs better on a 32-CPU box rather than 16x2.

I agree that in many cases, proprietary kit is overpriced and unnecessary. Which is why it's on the decline...

Re:What are these architectures good for...

[isj]

What keeps this SPARC space alive?

Solaris.
Sun has maintained backward compatibility for applications for decades. You rarely encounter "oops, you need libc.2.0, but that is not supported on the newer kernels.". Also, the command-line system administration tools (especially for troubleshooting) are comprehensive (dtrace, truss, ptree, prstat, psrset, ...)

Re:What are these architectures good for...

[segedunum]

You realize that the cheapest SPARC can handle more threads per cycle than a dual-quad Xeon, and do it while using less electricity, right?

The problem is that a Xeon will complete each thread [task] in far less time than the SPARC and be on to the next one, and the workloads that most organisations have are entirely dependant on completing ever increasing single tasks in the shortest amount of time possible.

Re:What are these architectures good for...

[segedunum]

Feel free to mod the parent up more, because that, sadly, is a true reflection of the way things have been for most of the past ten years - not just now. I worked somewhere eight years ago where someone realised that a desktop 1.4GHz Athlon had several times the performance of an expensive UltraSPARC III whilst troubleshotting some Python and Zope performance issues. It was justified because it was an 'enterprise' piece of kit and no one wanted to believe that they wasted their money on something so expensive.

To get close to an off-the-shelf AMD or Intel system performance-wise your SPARC systems need to be running hell-for-leather at 100%, drawing maximum power permanently. The Xeon or Opteron systems will be able to scale up and down far more comfortably, so when comparing these systems you are never comparing apples with apples because the performance is just not comparable. Unless you have thousands of *completely independent* requests to handle per second then a SPARC system is useless to you and the writing has been on the wall on that for the past ten years.

Re:What are these architectures good for...

[Macka]

Yeah, but the thing is that 32-CPU systems are incredibly niche. I've been involved in projects that delivered a number of systems of that size over the years and I can count on one hand the times they've been used as single 32-CPU systems. In virtually all cases they were hard partitioned down to 4, 8 and sometimes 16 cpu systems. And x86 is walking all over that market now. Next year when the Nehalem-EX chips ship, you'll get your 32 cores on a standard 4 socket server with twice as many threads. It just shoves the high end systems more and more into a tight corner. RAIDed memory is great, but that alone is not worth the premium that proprietary solutions are burdened with.

   

Re:What are these architectures good for...

[RubberDuckie]

There's a lot to be said for backward compatibility. I recently migrated a very old database off of a Solaris 2.6 system and moved it to Solaris 10. I didn't have to search for back leveled software, the application just worked. Granted, this isn't something I need to do every day, but it's an invaluable feature to have when you're dealing with trying to support enterprise applications that just refuse to die.

Re:What are these architectures good for...

[davecb]

Not joking, but betting that your business parallelizes wonderfully, so you can break up your transaction processing over a Beowulf cluster. Alas, large transaction processing tends to require something like a POWER or SPARC, to get 128 cores with a common locking architecture working on driving a large database.

This is the traditional IBM/SUN/H-P space, and fits, in rough order of difficulty, large manufacturing, large on-line retail, medium and higher regular retail, banks and telcos. Not my personal favorite businesses, but definitely where the majority of my income comes from (I'm a capacity planner).

--dave

Re:What are these architectures good for...

[lewiscr]

Several years ago, I had the opposite problem with a real world OLTP load. I replaced a 5 year old Quad SparcII 450MHz machine with a Dual Opteron 2.4GHz. The Opterons had 3x the total MHz, 4x the RAM, more PCI bandwidth, and faster disks. They were half the price of the Sparc relacements, so I was not allowed to evalate the Sparc options. I guestimated that the new Sparc option would have been 2x faster and handled 4x the transactions compared to the 5 year old machines.

The Opterons were slight faster, but did not handle load spikes nearly as well. Had I been allowed to purchase the 5 year old hardware used, I probably would have been better off sticking with the 5 year old hardware. If I allow hindsight, including all the architecture conversion problems and software upgrade issues I had, the old-but-tested hardware would have been a big win. (Note: I had the ability to scale my database horitzontally very easily, so old machines were still useful machines.)

For a database server, I highly recommend that a Sparc based machine be evaulated next to any X86 based machine. They cost more upfront, but I found them to be cheaper in the long run.

Re:What are these architectures good for...

[afidel]

Not to mention that everyone selling 4 way and larger x64 servers offers raided memory if you want it. My biggest gripe with x64 systems is the lack of sufficient I/O offloading. High workloads are fairly easily met by the CPU and memory subsystems but when it comes to moving big piles of data to and from the network and storage they kind of suck. We get fairly good performance by pinning our big database tables in memory and by using TOE cards (which are poorly supported) for networking. There is some hope on the horizon with many 10gig ethernet adapters being CNA's with a high degree of offloading, but it's one area where I think the x64 market needs to mature a bit more.

Re:What are these architectures good for...

[downix]

I've found the SPARC FPU to perform better than the Core 2's, a lot more reliably if nothing else. In addition, the SPARC's threads complete in less cycles, enabling a slower per-thread CPU to keep up.

Re:What are these architectures good for...

[K. S. Kyosuke]

Not to mention that threads (as in preemptive kernel threads) are no panacea for computing problems, no matter what Java fanbois think, so I don't think this is that much a loss.

Re:What are these architectures good for...

[John Betonschaar]

What OS did the Opteron run? I guess Sun puts a lot of effort to tweak Solaris for optimal performance in server tasks, so a desktop linux install on x86 with a low-latency kernel might in fact fall apart under high load, and comparing the two setups like that might be misleading. There's lots of ways to configure a linux kernel that really sucks under high load, even on the fastest of hardware. Try an early 2.6 kernel with the old VM, and you can slow a brand-new machine to a crawl by simply spawning a lot of processes that allocate/deallocate lots of large memory blocks.

Anyway, a 450Mhz Sparc beating a 2.4Ghz Opteron sounds like a fairy tale in my book. Of course compiling code or running FPU-heavy tasks isn't exactly comparable to serving webpages or querying a database, but seeing that an 1.5Ghz UltraSparc III takes over an hour compile the same source tree that keeps an el-cheapo Dell laptop busy for only a few minutes makes it very, very hard for me to believe your Opteron really didn't blow the sparc out of the water in any scenario imaginable.

Re:What are these architectures good for...

[John Betonschaar]

I'm really sorry but that just doesn't match my experience of reality.

The stuff I run on linux and solaris is about as FPU-bound as it gets, it does non-linear regression of sets of very complex, multi-dimensional model functions, inside the fitting loop it's all linear arithmetic (using LAPACK/BLAS on x86 and sunperf on Sun), lots of large matrix/vector operations, etc. I think I'd estimate the ratio of FPU code vs. control logic + system calls around 90%-10%. Since the model functions are separable over their output grid, they're easily parallized into strips, which we tried with 1, 2, 4 and 8 threads. The results on the 8-core M3000 where so disappointing we could hardly believe it, the performance simply scaled up with the extra Mhz, compared to our old Sun Netra 240, no more no less. Compared to our development machines (simple C2D laptops) or the Opteron servers running linux, fitting times on Sparc where literally 8 to 10 times slower. Clock-for-clock Sparc FPU performance was down 5 times over the x86 systems.

It's not that I hate Sparc or anything (I just hate solaris), in fact I do agree with something you posted earlier in this topic, that it's actually a good thing to have many different architectures (just for different reasons than you mentioned). But nowadays you just can't deny that the role for Sparc architectures has been reduced to massively parallel server tasks, and that's it.

Re:What are these architectures good for...

[lewiscr]

The Sparcs had Solaris 8 64bit, the Intel's had RedHat Enterprise 4.2 64bit. ...running MySQL. I think the problem was partly that MySQL had been better optimized for 64bit Solaris, but not not so much for the Intel. Mostly because X86-64 was new enough that it hadn't had time to be optimized.

It was a database server. I needed very little CPU and a lot of IO. The Sun machines are designed to do IO. Even their X86 machines do some nice things for heavy IO loads. For my comparison, the 5yo Sparc machines had nearly the same IO subsystem that the new X86 machines had.

So yes, I'm comparing apples to oranges. I replaced a machine designed to handle heavy IO with a machine designed to be a web server, then got upset when it couldn't handle the IO. But it's funny... when I try to find an X86 machine with a comparible IO subsystem, it costs more than the Sparc.

Re:What are these architectures good for...

[Macka]

Not joking, but betting that your business parallelizes wonderfully, so you can break up your transaction processing over a Beowulf cluster.

Nope. Only ever done one of those. It ran Fluent (on Redhat) and was for the Aerodynamics group for one of the Foruma One racing teams. The bulk of my experience comes initially from working for one of the big vendors, and then self employed as a consultant in banking, telcos, pharmaceutical and health. Some of the data crunching software typically deployed in these areas are: Ab Initio, Nucleus, Octopus and Oracle RAC.

Alas, large transaction processing tends to require something like a POWER or SPARC, to get 128 cores with a common locking architecture working on driving a large database.

Traditionally, yes. But times are changing as the top Intel Xeon and AMD chips are finding their way into systems that can easily deliver the horsepower to meet those needs. And memory capacity is no longer an issue either. Besides TPC performance is more sensitive to fast IO and lots of spindles for more IOPS than the difference between the fastest CPUs. Just take a look at the configs the system vendors put together to hit the top TPC benchmark results. The disks number in the thousands! And Oracle's fastest published results are on clusters of Xeon chipped systems.

Re:What are these architectures good for...

[amorsen]

You realize that the cheapest SPARC can handle more threads per cycle than a dual-quad Xeon, and do it while using less electricity, right?

Err, no. The cheapest SPARC is probably still some UltraSPARC IV+ thingy, and those are absolutely hopeless (and single-core). The T2 might have a chance on a few work loads, but Intel will very soon have 8-core 16-thread CPU's out with twice the clock rate and much better per-thread IPC than the T2.
 

As for the big-iron chips, they handle databases on a scale that dwarfs the address range of x86,

Nehalem supports 44 physical address bits. I'll bet you that there are no NUMA or SMP SPARCs out there with 16TB memory. Indeed, the T2 is limited to 40 address bits, or 1TB,.
 

relying on more registers than even exists in the x86 architecture.

The number of registers has absolutely nothing to do with scaling.

Re:What are these architectures good for...

[Macka]

I think 2010 will be a big turning point for x86, well specifically Intel's x86 anyway. There will be a convergence of technologies: Intel's new QuickPath Interconnect enabling high speed links between Nehalem-EX chips and IO Hubs on the motherboard, with affordable 10GigE ethernet, 8Gb/s FibreChannel and 6Gb/s for SATA. You'll probably still be pinning your big database tables in memory though as your expectations will be higher ;-)

Re:What are these architectures good for...

[Anonymous Coward]

Exactly what were you smoking at the time as I want some of that fantasy stuff as well. My SunBlade 1000 (2x900 8gb) sits next to my Ultra-24 (quad Core Du 2.4 8gb). The Blade 1000 completes my model runs in a little over 4 days while the Ultra-24 takes 5 days plus. Both machines are running OpenSolaris and use the SunStudio-12 compiler suite. The Ultra-24 compiles the package in about an hour, while the Blade 1000 takes about 80 minutes, but compared to the run time compile times are trivial. FP performance on an Intel chip bites the bag. You want to play your CS games with python go right ahead, those of us who actually use a computer for something other than making it easier for porn distributers to make animated web sites want a processor that performs.

Re:What are these architectures good for...

[mzs]

The M30000 has DDR2-533 ECC RAM, can you see now that you were not compute bound (unless your dataset was less than 4MB or so)? Also it uses Fujitsu SPARC64 processors which typically have worse FP performance than UltraSparc IV+ even years later. The other thing is were you doing 32-bit or 64-bit FP? By using 32-bit FP and the SIMD features on AMD/Intel that can be a lot faster than 32-bit FP. Sparc FP went through a few revisions over the years. What you have now is 32 double precision registers, the first 16 of which you can use as two single precision each or use them as pairs for 8 quads. The upper 16 can only be used as doubles. Some of the single precision operations are SIMD like, that was very useful in sparcv8 and made some single precision faster than double precision. Almost every sparc out today does all FP in double precision and creates a single precision result if it needs to. That is why double is just as fast as float. The instructions handled by the FP unit are very rich. The ones for quad are almost as rich, but some trap. There is also VIS (a SIMD extension for sparc) but relative to FP all it had were some instructions to more speedily get values in and out of the FP registers. The VIS 3.0 in RK (just cancelled) was going to offer more in the way of FP.

For performance measurements. When Opteron came-out it was faster than the fastest UltraSparc at 32-bit FP, actually by a good margin. It was a tad slower at double and did not have a snowballs chance in hell with quad (but nobody uses that). Then with the UltraSparc IV and IV+ sparc was again faster at all FP. The T1 and T2 were not as fast at FP as USIV and USIV has stagnated (RK was expected so USV was canned). We now again see that for single precision Intel (incredible strides) and AMD are faster than UltraSparc and are on the doorstep with regards to double precision. But again the memory being used in modern Intel and AMD machines is faster than that used in current Sparc kit. The FP on Sparc is so fast that it is memory bound in more cases than Intel and AMD, certainly in HPC types of workloads.

Re:What are these architectures good for...

[Macka]

You're not seriously attempting to take a back handed swipe at Linux by bigging up Solaris's command line admin tools are you? I mean, have you actually looked a recent release of Redhat or SuSE? You must be barking mad. Linux has a very rich and comprehensive set of command like tools at its disposal. Your few examples are easily matched:

dtrace = systemtap
truss = strace
ptree = pstree
prstat, prset = taskset

     

Re:What are these architectures good for...

[Macka]

whoops, I'm getting sleepy.

prstat =ps

Re:What are these architectures good for...

[isj]

No, I am not dissing linux. The linux system administration tools have caught up.

Re:What are these architectures good for...

[davecb]

Well, I helped build one system which would scale the way Oracle demonstrated with RAC, but it was distinctly unusual: a library system, where the operations were the idempotent borrowing of a particular copy of a book by a particular patron.

So there's a proof of concept, but it's the only one I've seen thus far, in a fair career as a capacity planner.

All the rest have been pretty ordinary large-transaction business systems, which get their performance from being able to apply lots of processors on a fast backplane for fast consistency checking and raw lock speed.

I speculate that we may need a new form of normalization, one making as much of a transaction run without involving locking, just like the normalization for relational databases made redundant-item updates in network databases unnecessary...

--dave

Re:What are these architectures good for...

[downix]

I own two SPARCS (3 MIPS, a PPC, an Alpha, but I digress). I use them for heavy IO tasks, in my cases one is a NAS (a job which it does admirably) and the other is my router/firewall (a task which it also does admirably). In my testing, the SPARC can be used for other tasks very well. My guess is that both Sun and Fuji fail to see outside of the head-of-the-class server market in order to broaden the demand. It's like they can only see the big boss, without realizing that the key into the office is through the secretary.

The router is the funniest thing to see in action. Dual 32-bit HyperSPARC CPU's, 9 NIC ports, and a wireless, all run by OpenBSD. And it performs admirably for my 12-system network, handling all of their needs without even a murmur of a hiccup, something my old Linksys never could.

Re:What are these architectures good for...

[Anonymous Coward]

~/Desktop$ uname -a
Linux node34 2.6.30-9-generic #10-Ubuntu SMP Fri Jun 12 13:08:18 UTC 2009 x86_64 GNU/Linux
~/Desktop$ file debian-1.1/bin/gzip
debian-1.1/bin/gzip: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), stripped
~/Desktop$ sudo chroot debian-1.1/ /bin/gzip --version
gzip 1.2.4 (18 Aug 93)
Compilation options:
DIRENT UTIME STDC_HEADERS HAVE_UNISTD_H ASMV
~/Desktop$

Re:What are these architectures good for...

[chez69]

actually java fanbois like myself like faster CPUs, and educated ones know that threading and preloading craptons of shit into memory can't rescue bad code.

Re:What are these architectures good for...

[Anonymous Coward]

So, you look at a couple of toy applications you have and scale them up to server workloads? dude your full of shit. SPARC is dead, it can't compete with raw power, I can't wait to take a piss on the last POS sun server.

Re:What are these architectures good for...

[Anonymous Coward]

I'd guess a Power6 server or a rack of Opterons or Xeons wouldn't do much worse.

I work daily with Power hardware. The sheer amount of computing power is staggering, I have never seen anything quite like it anywhere else. The hardware is extremely expensive, but on the other side running an enterprise web site while bothering to give all the servers (J2EE platform, databases etc) combined one whopping core and things just still running smooth, ... It's hard to describe really.

MySQL

[gubers33]

I don't care too much about a over delayed processor, as long as they don't get rid of MySQL or make it a paid service I will be happy.

The summary is misleading....

[paulsnx2]

Rock was Sun's effort to develop a processor with high single thread performance. Single thread performance doesn't help the database performance of Sun' s new Oracle Over Lords. What databases need is high multi-thread performance.

The Niagara line ( http://en.wikipedia.org/wiki/UltraSPARC_T1 ) provides the proper architecture for improving database performance, and this effort by Sun has the added benefit of actually producing shipping products (Unlike Rock).

At this time, Oracle/Sun has NOT announced the killing off of further Niagara development.

Re:The summary is misleading....

[k8to]

The Niagara line of CPUs might look like a reasonable chip, sadly the servers they are sold in have terrible I/O profiles. A rebrand will be needed to shake that legacy.

Really though, everyone I know in database optimization is on x86 with just more boxes. Sure this doesn't work for all problems, but for all the real world business problems I hear about, they seem to be making it work.

Re:The summary is misleading....

[Anonymous Coward]

Cite some sources? What do you mean by I/O profiles? T5220s running Sybase seem fine.

Re:The summary is misleading....

[paulsnx2]

"... is on x86 with just more boxes..."

As long as your application doesn't care about power (where most of my projects are large scale and DO care about power), adding more x86 boxes works just fine.

good night,

[Icegryphon]

sweet prince...

Mistake in tags

[Anonymous Coward]

As I am reading this, I can't help but be saddened at the mistaken tag 'paperrocksun'. Obviously, rock is defeated by both paper and sun, which is contrary to the paradigm of the game. A better tag would have been: rocksunscissors.

Shame on you /.
Shame

Re:Mistake in tags

[onemorechip]

Sun kills rock, rock smashes scissors, scissors cut paper, paper disproves Spock, Spock vaporizes rock, rock smashes lizard, lizard poisons Spock, Spock shorts Sun, ...

Oracle will jettison the entire hardware division.

[reporter]

Oracle will discard the entire hardware division (of Sun), not just the processor departments.

Unlike Sun (which will no longer build processors), Fujitsu does build processors and the servers that incorporate them. Building the processors gives Fujitsu engineers intimate knowledge of how the chips work and enables the engineers to optimize the processors' connection to the rest of the server ecosystem. Lacking this ability, Sun engineers will not be able to build servers that match the capabilities of Fujitsu's computers.

The logical conclusion is that Oracle will jettison the entire hardware divison. That is not surprising. Oracle was mainly interested in Sun's software products (e. g., the operating system) and Sun's customer lists. Larry Ellison was willing to overpay for Sun (buying the hardware division in the process) simply because he and Scott McNealy are good friends.

Note that Sun once boasted that it employed about 1000 (?) microprocessor engineers. Sun claimed that it had the largest processor team outside of Intel. Apparently, quantity does not necessarily lead to quality.

N N O O o o . . . .

[jamesswift]

I really wanted to see someone succeed with HTM http://en.wikipedia.org/wiki/Transactional_memory :'(

Re:N N O O o o . . . .

[K. S. Kyosuke]

Yep, it seems this one has now gone the way of Lisp Machines... Well, we can still hope for some AMD64+ architecture in the future.

So, basically,...

[John Hasler]

...the entire world is to be forced onto the X86 monoculture (except perhaps for a few ARMs at the low end). Something else for which we can thank Microsoft.

Re:So, basically,...

[akadruid]

It's closer to the other way around; ARM is the mostly widely used 32 bit architecture, and accounts for more than 75% of all 32 bit processors sold.

Really, the entire world has been forced onto the ARM monoculture (except perhaps for a few x86s at the high end).

Re:So, basically,...

[Darinbob]

And some PowerPC system-on-chips in the middle.

Though the high end ARMs may giveit a good run for the money. The ARM family is getting too complex in my opinion, with multiple instruction sets. Despite the RISC heritage it's no longer an architecture for the keep-it-simple-crowd.

Re:So, basically,...

[mzs]

In the middle it is looking like Atom is in a very good place, as has PentiumM on PC104 (and PCI brethren) for a while. PPC is being squeezed-out of that arena especially with the motorola to freescale and emerson sales. IBM does not serve the likes of emerson and GE well.

Re:So, basically,...

[Darinbob]

Except that the x86 family is such a nasty architecture. Bringing us back to the point that we're becoming a world with nearly a single universal computer architecture, except for embedded systems. And even there Intel is making headway.

But it's not so cut and dried anyway. Here's an older but still mostly relevant descriptions of ARM vs PPC vs X86.

http://www.ibm.com/developerworks/library/pa-migrate/

Re:So, basically,...

[Anonymous Coward]

I don't see how this is Microsoft's fault. WinNT was originally written for the i860 and MIPS architectures, and only ported to x86 sometime later. It released simultaneously in 1993 for x86, MIPS, and Alpha. In 1995, the PPC version shipped, and the Itanium version shipped some years later. The reason MIPS, Alpha, and PPC were discontinued is that OEMs stopped building workstations that supported it. You can hardly fault MS for that!

If MS never gave you a choice, you could argue that it's their fault we have a monoculture, but it's clearly not the case. People run x86 because it's cheap for the performance you get and everything is already compiled for it. Just look at Linux: it runs on 30 different platforms, but 99% of its users run x86. Why? Because it's cheap and everything is already compiled for it. Can you blame them?

dom

Re:So, basically,...

[Anonymous Coward]

Don't forget Hitachi's H8 and SH in automotive. Low margin but installed hardware base in the millions. Granted, the software base is very narrow in scope, compared to ARM and PPC, and the open-source scene is a small academic blip. Nevertheless, they have some pretty cool SoCs, I'd like to get one on a PCIe card...

The whole *article* is misleading....

[davecb]

The article reads a lot like FUD written by Microsoft about particularly threatening Linux advances.
I just benchmarked a huge Oracle configuration on T5240/T5440, M5000s and M9000s, and it really made my little heart beat fonder (;-))

--dave

This Was Always Going to Happen

[segedunum]

As soon as a group of people got into Sun, looked at the costs of maintaining and pumping research and development into their hardware, looked at the relative performance from SPARC versus competitors using x86 and ultimately looked at the bottom line objectively without being stupidly protectionist, then the next step was going to be shutting down Sun's production of Rock and SPARC and moving it to Fujitsu as a supplier to save money. However, even that probably won't be enough as I'm not sure Fujitsu will be able to keep SPARC viable themselves. SPARC has had two, possibly three, options written on the wall for the past ten years:

1. Catch up to x86 platforms in terms of raw performance as most SPARC systems have tended to overlap with workloads x86 systems have taken over. Papering over cracks by promoting 'CoolThreads' and parallel processing as a way around this performance gap was never going to work. I can remember almost ten years ago working somewhere where a person discovered that their Athlon 1.4GHz desktop system had several times the performance of their UltraSPARC III server and could complete tasks several times sooner. Cue lots of panic as UltraSPARC was justified because it was 'enterprise' reliable.

2. Accept the inevitable and throw the towel in.

3. The third way: Do what IBM has done with Power and push it into a high-end and high premium niche. This is difficult because IBM itself can only cover Power by selling mainframe packages and a whole bunch of add-ons to make it pay. Sun have had difficulty with this because their hardware division has always relied on hardware sales themselves.

Option 2 has clearly become the only way out once Sun's difficulties resulted in a takeover and as poor as Oracle might be at some things they are extremely successful at judging bottom lines.

Re:This Was Always Going to Happen

[downix]

Funny thing is, I run an US II and find it's faster than a Pentium III of almost 5x the Mhz. You classify this as the platform, I spot it for what I and a lot of others recognize as a weakness of the US III. The III was Sun's P4, a high-priced pretty poor CPU.

Re:This Was Always Going to Happen

[davecb]

Actually Sun's been doing 3) for years, designing chips to work with a big fast backplane (ex-CRAY, at one time), and which Fujitsu has specialized in.

The Rock is their high-clock-speed box, not their big database box.

--dave

Re:This Was Always Going to Happen

[mzs]

I'm guessing yours is not 400MHz 4MB non-mirrored e-cache model, but I digress...

The USII was arguably the best at the right time processor to come out of Sun. Its competitors were Power3 (came out the next year), Alpha 21264, PA8500, and R12000. Nothing from Intel or AMD at the time came close. The Power3 was the closest in performance, better in some respects, but AIX was very not pleasant and the cache tended to be better on the USII for the same price. The Alpha was getting dated, but you could get ones at fast clock speeds with lots of cache, again more expensive. The HP and MIPS were showing their age at that point.

The USIII was a very bad processor in terms of MIPS, power consumption, and cost. It was also over two years late. The IIIi was a good one though. When it came out Sun had boxes with 4 USIIIi procs and 8-16GB ram at great prices. Too bad dot-com was collapsing around them at the same time.

Re:This Was Always Going to Happen

[Anonymous Coward]

Funny thing is, I run an US II and find it's faster than a Pentium III of almost 5x the Mhz.

No you don't.

INT:
http://www.spec.org/osg/cpu2000/results/res2000q3/cpu2000-20000810-00176.html
http://www.spec.org/osg/cpu2000/results/res2000q4/cpu2000-20001129-00408.html

FP:
http://www.spec.org/osg/cpu2000/results/res2000q3/cpu2000-20000810-00177.html
http://www.spec.org/osg/cpu2000/results/res2000q4/cpu2000-20001121-00355.html

Summary of those numbers:
UltraSPARC II 480 MHz scores 234 SPECint2000, 291 SPECfp2000
Pentium III 1000 MHz scores 462 SPECint2000, 340 SPECfp2000

So, at a ratio of just over 2x clock rate, the P3 is ~2x faster at int and 1.16x faster at FP. Which makes your claim that an US II can beat a P3 clocked 5x faster completely absurd -- question SPEC's methodology all you want, you're completely out of touch if you are that far away from them.

(Of course, 'downix' is not anyone you'd want to consider an authority on anything, much less a legitimate challenge to SPEC's ability to design a proper benchmark. You're a pathological liar who has been faking expertise for years... 'Eddas' ring a bell?)

But you weren't done! You went on to stick your foot even further in your mouth:

You classify this as the platform, I spot it for what I and a lot of others recognize as a weakness of the US III. The III was Sun's P4, a high-priced pretty poor CPU.

A little more searching on the SPEC website reveals that (just to pick one example pair of scores) a SunBlade 150 with a 650 MHz US IIi scores 246/276 int/fp, and a SunBlade 1500 with a 1.062 GHz US IIIi scores 589/884.

And in another message you claimed:

I've found the SPARC FPU to perform better than the Core 2's, a lot more reliably if nothing else. In addition, the SPARC's threads complete in less cycles, enabling a slower per-thread CPU to keep up.

Bull. Complete bull.

Let's consider SPEC CPU2006 this time, only because the old CPU2000 benchmark probably hasn't ever been run on a Core 2.

It so happens that CPU2006 is normalized to an UltraSPARC 2 running at 296 MHz (the Ultra Enterprise 2). In other words, that processor by definition scores 1.0 on both the integer and FP tests.

The 2.66 GHz Core 2 Duo E6700 scores 20.0 int, 16.9 fp.

Even if you have the fastest US II ever made (the 650 MHz US IIe+), there is simply no way your US II's FP performance could even *touch* a Core 2's. You're in the realm of completely ludicrous claims, here.

You can't even save yourself with a weak back-off to per-cycle efficiency: notice how the C2's clock is less than 10x as much as the US II, yet its performance is much more than 10x higher?

Nate, why do you so often feel the urge to lie about things like this?

Re:This Was Always Going to Happen

[downix]

For some odd reason you seem to rate integer and fpu as the measurement of performance. By that measurement, Itanium is a speed demon. As the rest of the world seems to know, there is more to speed than just benchmarks, unless you run benchmarks for a living. I speak of personal observations, "finding" things, rather than hard numbers because, frankly, there are lies, damned lies, and statistics. I compared my 200Mhz US II to my 1Ghz Pentium 3, and it responds faster, smoother, slicker. Both running Solaris 10, mind you. Now, for things like compiling, yes, my old NAS host here is bog slow. However, for the job I have it doing, it definately fits my bill.

I'd also make note that I never claimed a US II FPU beats a C2D FPU, but that a SPARC FPU does. Did not specify, because I was discussing architectures. If you insist on numbers, let's look at your SPEC2006 for the 2.66Ghz C2D E6700, 16.9 fp. Now let's compare that to a SPARC FPU, 28.8 by the SPARC 64 VII running at 2.5Ghz, slower than the C2D.

Now, with that said would I use the SPARC for a gaming solution? Hardly, it's not ideal for the job. I'd sooner use a MIPS or x86 for that. But for repeated remote file access, the SPARC is one of the kings of the field, handling peak loads that my old P3 never could.

And being that you like looking like an AC fool, might I remind you, SPARC's not even my preferred architecture.

Re:This Was Always Going to Happen

[downix]

Yes indeed. I was impressed when they turned to the old II design for the Niagra chips, similar to how Intel turned to P3 for the Core series development.

I'm also speaking "feel" when it comes to the US2 vs P3 comparison, I had a 1Ghz P3 as a NAS, which consistantly choked on high access loads. I when picked up an old USII I put it in the same place, controlling my networked hard drive, the difference was night and day. Same Adaptec SCSI controller, but I was getting far faster responses from my network requests of data. Now the same machine sports a SATA HDD controller and a much larger drive, still purring happily.

Just checked, I was mistaken tho, it's a 250Mhz USII, so would be 4x P3. My mistake.

Re:This Was Always Going to Happen

[Anonymous Coward]

For some odd reason you seem to rate integer and fpu as the measurement of performance.

Nate, dear boy, CPUs do integer and floating point computations. Would you care to inform us what other kinds of computations they do in order that we might measure them?

Is SPEC the ultimate measure? No, it's got plenty of known flaws, but it is a decent approximation as long as you take appropriate care when looking at submitted results (more on that below, as you fell for an intentionally misleading score).

As the rest of the world seems to know, there is more to speed than just benchmarks, unless you run benchmarks for a living. I speak of personal observations, "finding" things, rather than hard numbers because, frankly, there are lies, damned lies, and statistics. I compared my 200Mhz US II to my 1Ghz Pentium 3, and it responds faster, smoother, slicker. Both running Solaris 10, mind you.

The only reason you can imagine for a difference in subjective responsiveness is processor performance? Then you don't know anything.

If you insist on numbers, let's look at your SPEC2006 for the 2.66Ghz C2D E6700, 16.9 fp. Now let's compare that to a SPARC FPU, 28.8 by the SPARC 64 VII running at 2.5Ghz, slower than the C2D.

And here's where you fell for some 'creative' benchmarking. SPEC has always been the target of a lot of gaming by vendors, so you do have to take care.

Non-'rate' SPEC2006 is supposed to be a measure of a single CPU core, even in a multiprocessor system. This means that the scripts which run each benchmark in the SPEC suite only start one copy. (The 'rate' version starts N copies, where N is determined by the organiztion running the benchmark, and scores the throughput of the test as a whole.)

In recent years, autoparallelization compilation technology has been advancing. An autopar capable compiler can analyze the source code it's given and (sometimes) figure out ways to transform a single thread into multiple threads. If it does so, it inserts code to spawn threads and distribute work across however many processors are found at runtime.

Now, that's a useful thing, but if you allow autopar in a benchmark like SPEC2006, benchmarks may actually take advantage of multiple CPUs when the intent is to measure just one. Unfortunately, the SPEC2006 rules do allow autopar to be turned on, even in 'base' mode ('base' scores are supposed to have stricter rules for allowed optimizations than 'peak' scores). SPEC only requires that submitters must disclose the use of autopar.

This makes SPEC submissions with autopar enabled somewhat useless, because they don't measure what they're supposed to measure. Here's the source of your 28.8 CFP2006 score:

http://www.spec.org/cpu2006/results/res2008q3/cpu2006-20080711-04753.html

Look at the graphs of individual programs in the suite. Notice how 410.bwaves, 436.cactusADM, 459.GemsFDTD, and 470.lbm are all ridiculously high, and 434.zeusmp and 437.leslie3d are suspiciously high? Each score is the ratio of the execution times of that benchmark on the tested system and a reference system (a 296 MHz UltraSPARC II). It's simply not credible that a Sparc64 VII is 495x faster when running 410.bwaves but only ~11x to ~16x faster on most other benchmarks in the suite.

Scroll down further and you'll find the disclosure that they used autopar in the "Software" box. And in the Hardware section, you'll find that the machine tested has 64 CPU cores. Suddenly that 495x result makes a hell of a lot of sense. The multi-CPU scaling isn't perfect in every benchmark where autopar is able to do something, but autopar technology is not perfect, and for that matter few programs are capable of scaling linearly with the number of CPUs.

SPEC uses a geometric mean of the individual scores to calculate the final result, to reduce the impact of o

Re:This Was Always Going to Happen

[downix]

>What's more, file server performance involves many things other than the CPU. It's usually more about I/O
>performance than anything else. You're comparing a workstation or server which was designed for really solid
>I/O performance to (I'm guessing) some random cheapass P3 motherboard designed to run Windows.

In the end, what you say here is really the only point I was trying to make here, that the CPU is not the end-all-be-all for a systems performance for a particular task. So thank you for reinforcing that. I'm not trying to proclaim that the SPARC or any other CPU is an ultimate processor, I've grown past that stage. Instead, I'd rather focus on getting the right part for the job. And yes, I do enjoy playing devils advocate, to try and bring a different view to the table.

Re:This Was Always Going to Happen

[downix]

And just so you know, I am aware of how over-optimistic I was with Eddas. By the time I'd gotten the design down, the needs changed, so redesign, again, needs changed, and before I knew it, 28 revisions to the design, and still it would not be enough. I learned a very big lesson with that, timing is everything, and don't over-estimate your own skill at something. I look over the sketches on rev 29 from time to time, and realize, yes, I could finish it. But then what, you know? Being over optimistic, wanting to take down the goliaths as some cyber-daniel is a game for the young.

Re:Oracle will jettison the entire hardware divisi

[Just Some Guy]

The logical conclusion is that Oracle will jettison the entire hardware divison.

I don't think that'll happen. I think Larry wants you to buy Oracle (the database) running on Oracle (the OS) on Oracle (the hardware) and support contracts for the entire stack. There's a lot of PHB love for being able to call one phone number for anything that breaks because the same company is responsible for every component. IBM currently offers this, and now Oracle can, too.

Perhaps Fujitsu's SPARC line

[bugs2squash]

will return to profitability and be able to support more R&D because of this.

heat?

[Anonymous Coward]

Well there's IBM. And they don't seem to be slowing down:

POWER 6

POWER 7

also:

http://www.theregister.co.uk/2008/07/11/ibm_power7_ncsa/

POWER 7 sounds like crazy town...

The one thing I like about the Niagara-based CPUs (UltraSPARC-Tx) is that they're fairly low wattage for the work that they can do. These 4 and 5 GHz chips from IBM seem like they're going to be dumping heat like mad.

Unless you're doing HPC, and are willing to go into water-based cooling in your DC, it seems excessive to some extent.

Anyone have experience with POWER and how it differentiates with SPARC? It seems that there's a product split in SPARC, but everyone else (IBM, Intel, AMD) seems to have a one-size-fits-all kind of thing.

Re:Oracle will jettison the entire hardware divisi

[davecb]

No-one in their right mind buys something they don't want because their friend is the salesperson. Much less pays extra for it!

Larry is way smarter than that, and I suspect he's looking at the chance to go from a database company to a whole-line vendor, just like IBM was back in the mainframe days.

I'll happily believe IBM would have laid off everyone, starting with the hardware folks. I'll bet they're cursing having missed the chance to buy Sun.

--dave

Re:Oracle will jettison the entire hardware divisi

[idontgno]

I don't think that'll happen. I think Larry wants you to buy Oracle (the database) running on Oracle (the OS) on Oracle (the hardware) and support contracts for the entire stack. There's a lot of PHB love for being able to call one phone number for anything that breaks because the same company is responsible for every component. IBM currently offers this, and now Oracle can, too.

True. But none of the above requires Oracle to manufacture one screw, chip, or board of hardware. OEM servers from Fujitsu (or Dell, or anyone they can trust and wangle a good price out of), slap on some Oracle name plates, et voila, the complete Oracle stack. Shoot, go nuts and do careful integration engineering so that the software is well-tuned and thoroughly optimized to the selected hardware. Subcontract HW and OS support out of the OEM vendor. Put them on-site with your Oracle weasels and make 'em wear Oracle name badges. Who'd know the difference?

It was inevitable. Sun has relaxed and turned its back to Oracle, and the long knives are slipping out of the sheaths.

Most exciting architectural development

[Anonymous Coward]

As a grad student studying computer architecture, Sun's Rock processor was one of the most exciting new architectures in the past few years.

Scout Threads offer a lot of potential performance for single threaded applications. A T2 can provide great throughput for a database, but the latency of individual requests is relatively high because of the very simple architecture. Rock offers the possibility for lower latency requests, although this comes at the cost of using more power.

Rock also includes support for Transactional Memory, which has been a hot-topic in research for many years. T2 is great for applications that are highly parallel, but if you don't know how to write parallel programs, all those threads are wasted. Transactional Memory provides a simple paradigm for writing parallel applications more easily than traditional paradigms.

The fact that Rock includes both of these features made it very exciting and interesting. I think it's unfortunate and disappointing that Rock is getting killed before we get to see what it can really do. The first Itanium chip was terrible, but Itanium II was much better, and actually does a good job in a specific niche. The first Rock might not be perfect, but it represents a significant departure from previous designs, and I think it deserves a chance to prove itself and find its niche.

Re:Most exciting architectural development

[Anonymous Coward]

Sorry to burst your bubble but hw scout was very poor performing. There are too many branches in real world code. The results of simulations showed that it was not a big win for a whole lot of extra memory bandwidth than simple speculative prefetching. It required extra transistors and would increased the chances of flushing a cache line that would need soon again. It simply would have been smarter to use that space for more cache and tags.

Transactional memory is why RK got delayed by 2.5 years. In the current implementation an interrupt occurs or the other core on die does a divide, and the transaction fails and has to be redone. How is this better than a software approach based on reservations on cache lines like other long standing approaches? More over due to the widespread adoption of posix, pthreads locking primitives are used in almost every real world case. The only place transactional memory is exciting is in lockless algorithms that grad school students come-up with. Virtually no one understands the MESI and even less people understand memory ordering, so likely anything out of the ivory tower will only be successfully applied in HPC, and just be poorly (bad bus utilization or buggy implementation) just like the research in the are of the past in the mid '80s. Old bad ideas are new again.

Re:Most exciting architectural development

[Anonymous Coward]

I am (was) a designer on Rock, and I can absolutely state that TM was *not* the big reason for the delay. There is no relationship between when an interrupt occurs or "the other core on die" does a divide and a TM fail. The way you state it shows that you know very little about how Rock works.

Like any architecture, you learn more about it with each generation. Unfortunately, various circumstances did not allow us the opportunity to get past the first generation.

Re:Very Interesting...

[Anonymous Coward]

hey looks like it sunk like a rock too.

Re:Oracle will jettison the entire hardware divisi

[fm6]

Oracle will discard the entire hardware division (of Sun), not just the processor departments.

Right. Spend $5 billion dollars for a company and then shut down 90% of it.

R.I.P. SPARC

[OrangeTide]

You will be missed.

I don't think that's right--

[bill_kress]

I don't think Sun kills rock--I think sun burns paper, paper covers rock and rock blots out sun..

Read this ...

[Anonymous Coward]

Rock, Sun's third-generation chip-multithreading processor, contains 16 high-performance cores, each of which can support two software threads. Rock uses a novel checkpoint-based architecture to support automatic hardware scouting under a load miss, speculative out-of-order retirement of instructions, and aggressive dynamic hardware parallelization of a sequential instruction stream. It is also the first processor to support transactional memory in hardware.

http://ieeexplore.ieee.org/xpls/abs_all.jsp?isnumber=4812126&arnumber=4812132

Re:Read this ...

[dlb]

That should all be in past tense.

Oblig.

[ThatsNotPudding]

"We won't, we won't rock you!!"

Resignation

[Darinbob]

I for one, welcome the continued occupation of our x86 overlords.

Linux not Microsoft.

[TheLink]

If you're talking about companies going from SPARC to x86, Linux is far more responsible for that than Microsoft.

Linux+x86 is Solaris+SPARC's main competitor. Not Microsoft Windows+x86.

The stuff people would want to run on SPARC machines, can usually be run on Linux+x86 with decent performance (and often better price/performance).

And if they really wanted they could also do Solaris+x86. So Sun's also responsible for that...

If people like vmware manage to provide _seamless_ high availability features that are less buggy than good hardware, the x86 stuff will crush the high end HA server market too.

Re:Oracle will jettison the entire hardware divisi

[raftpeople]

90% of annual revenues does not equal 90% of value to Oracle. Hardware is a competitive low margin business, software is high margin. Oracle is a software company, why lose focus and expend energy in a low margin business? They will probably chop anything unprofitable (e.g. Intel won the war, to compete in chips you need serious volume) and milk the install base for some time.

Re:Very Interesting...

[Chris Burke]

How's the economy over there?

Terrible, but I'm hopeful President Oprah will be able to turn things around.

Re:Oracle will jettison the entire hardware divisi

[davecb]

128-core SMP enterprise hardware is not a competitive low margin business: 1-4 core small servers are. For the latter market, Sun sells 1U AMD and Intel boxes (;-))

--dave

Re:Oracle will jettison the entire hardware divisi

[deanston]

Not logical at all. Apple does not fabricate it's own chips but it's in the hardware business just fine.

If I have an issue setting up my grid and have to call Dell and Oracle and Redhat to find what's wrong with the configuration, alternatives will become attractive. Oracle is in this for the whole stack. Attract and retain customers by simplifying the number of contracts they have on maintenance. Oracle just need to assemble and support the vertical stack. Where the separate parts come from don't matter.

copy cats

[OrangeTide]

Don't worry in 6-8 years Intel will copy all of that. Just like they copied SMT (called hyperthreading by Intel) from Sun.

Re:copy cats

[mzs]

If you mean SMT as is in mutli processor, Sun copied that from other folks. If you actually mean HTT then Intel came-up with that years before the T1 from Sun. Though the T1 uses more of a CMT idea. HTT was pretty bad in the P4, but returns in Nehalem. It works in a different way than the Sun Niagara approach (only issues so many instructions per clock and from two threads to fill in pipeline bubbles) But with the pipeline much wider than on P4 it is much better and fairer. That said if both of your threads are saturating all of the AU say, you won't get a lick of better performance. The Niagara approach is different. It switches threads in certain situations (like waiting for a cache line to fill) but you can see the same kind of problem as on Intel's HTT when all your threads are doing a lot of FP.

Re:copy cats

[raftpeople]

You mean Symmetric Multithreading, the thing first invented by IBM in 1968? It's computers, everything was invented in the 60's.

Re:copy cats

[OrangeTide]

No I said SMT and I mean it, as in simultaneous multithreading. And IBM's research never was productized, I bet you can't even tell me what architecture it was for. I'll make it multiple choice for you: STRETCH, ACS-360, ROMP, NORC, or PERCS.

I will concede that Intel (through Intel's purchase of DEC's chip unit) had SMT before Sun. And Intel was also the first to market (I think).

I guess Sun had nothing first. not SIMD. not RISC. 64-bit cpus were done by DEC about 3 years before Sun did the V9 aka UltraSPARC.

Re:Oracle will jettison the entire hardware divisi

[mzs]

Apple has a history of making ASICs. In fact the first intels were the first case of no Apple ASICs. The last example was the PHB chip on G5 systems, Apple designed, IBM fabbed. In fact they currently sell chips for iPod authentication fabbed in Taiwan. The rumors are that they are designing the SoC for a new line of small devices. Apple is very much in the hardware design game and positions continue to show-up on job listings.

Re:Oracle will jettison the entire hardware divisi

[raftpeople]

But you can't cherry pick the most expensive (and highest margin) servers because there isn't enough volume to pay for the chip r&d and production. Gross margin for companies like Oracle and Microsoft (80%) is about double IBM and Sun (40%) server businesses.

If you get rid of processor business (which most need to do) to make sure you don't have to pay for all of that r&d (and possibly fabs) then you have a much harder time differentiating yourself from the competition. Additionally Intel is making procs that continue to move up the ladder beyond just departmental servers.

Re:Oracle will jettison the entire hardware divisi

[tandr]

Oh G-d, please let it happen! I also sincerely hope Apple will be able to pick it up, and together they will have good UI and good servers!

Re:Oracle will jettison the entire hardware divisi

[fm6]

90% of annual revenues does not equal 90% of value to Oracle.

Maybe not, but it's worth something. The other 10% is worth pretty close to nothing to Oracle. Yeah, it's "high margin" (when it makes a profit at all), but in dollar terms it's hardly worth Oracle's time, never mind $5 billion in cash.

Re:Oracle will jettison the entire hardware divisi

[raftpeople]

Oracle wanted the 1% - Java, Solaris and customer base

They are going to find a way to make money with the hardware because you can't just get rid of it without seriously pissing off customers that also might/already purchase Oracle DB or applications. But you can bet they are going to be smart about the process.

Re:Oracle will jettison the entire hardware divisi

[fm6]

I'm confused. Are you disagreeing with me or not? Because you seem to have just said that they won't shut down the hardware operation. Which is what I'm arguing.

Re:Oracle will jettison the entire hardware divisi

[davecb]

You don't cherry-pick just that, but you'd be foolish to throw it away and consciously go to a just low-margin mass market.

Instead, one might want to start a line of very-many-core processors, to make it more cost-effective than a whole rack of mass market uni- to quad-processors (;-))

I just did a benchmark and capacity planning project using T5240s a front ends and (compute-intensive) middleware machines, and they did better on both price-performance and plain raw performance than the equivalent x64s, so for that workload set, choseing the masm market chip would have cost the customer real money.

--dave

Re:Oracle will jettison the entire hardware divisi

[raftpeople]

A little of both, but for different reasons. I agree that they are not going to shut down the hardware operations just like that, but not because that's what they wanted to get out of this purchase. I think it's more out of necessity: probably would have been tough to complete the software only deal with IBM trying to buy the whole thing.

So now they have an unprofitable hardware division that also happens to be in a pond that is getting smaller every day due to Intel. But if they just shut everything down then IBM or HP swoops in and controls the customers and potentially software and services that can get sold into those shops. So they do what they have to do to make money on the hardware: cut expensive development that simply is't going to have a return (new processors), and provide the customers with enough hardware to keep them happy as they slowly transition to Oracle Intel servers over the next 5 to 10 years.

The Rock

[mrbugjacobs]

WHAT ? They killed "The Rock" ? You bastards !!! http://en.wikipedia.org/wiki/Dwayne_Johnson/

Re:Oracle will jettison the entire hardware divisi

[hotfireball]

Oracle will discard the entire hardware division (of Sun), not just the processor departments.

This is called simply a bullshit. And that's why:

Oracle plans to grow the Sun hardware business after the closing, protecting Sun customersâ(TM) investments and ensuring the long-term viability of Sun products. Oracle also intends to focus the server and storage businesses on our common enterprise customers, where we believe we bring competitive advantage, relationships, and a track record of helping to reduce costs and complexity. Key to this strategy will be our plans to develop software-optimized hardware that integrates all of the enterprise components: hardware, database, middleware, and applications. After the closing, Oracle plans to be the only company that can engineer an integrated system where all the pieces fit and work together so customers do not have to do it themselves. Our customers benefit as their systems integration costs go down while system performance, reliability and security go up.

-- http://www.oracle.com/sun/sun-faq.pdf

IOW, it means they are much more serious than just kill. They want to be an IBM and seriously compete with M$ as well.

Another x86 casuality

[A12m0v]

Please let Itanic be next!

No one can stop the x86 train!
Not even Intel!

Re:Oracle will jettison the entire hardware divisi

[fm6]

So now they have an unprofitable hardware division that also happens to be in a pond that is getting smaller every day due to Intel.

Sun makes commodity computers too. They haven't marketed them very effectively because the sales organization is still in a Sparc-uber-alles mindset. Despite this, some of Sun's biggest profit centers are in the x64 arena.

Some of these products are pretty cool. This beast squeezes 8 Intel-compatible CPUs into a 4 rack-unit space, something nobody else can do. This one does the same with 48 terabytes of disk. This blade module squeezes four Nehalem processors into an absurdly small space and and been generating tons of orders from people looking to build huge HPC clusters. And of course there are the usual 1U and 2U systems.

Oracle is saying they can squeeze $1.5 billion in profit out of Sun in the first year. Assuming that this isn't BS, the only way they can do this is by drastically boosting hardware sales. Which is actually doable, with better marketing (including more emphasis on systems people actually want to buy) and sales, and access to Oracle's huge sales channels. (Oracle has more sales people than Sun has employees.) In any case, that scenario makes a lot more sense than the common assumption that they're dropping $5 billion just to acquire some not very profitable software assets.