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


Forgot your password?
Sun Microsystems Businesses Databases Oracle Programming Software Hardware IT

Sun Kills Rock CPU, Says NYT Report 190

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

Sun Kills Rock CPU, Says NYT Report

Comments Filter:
  • by Anonymous Coward


    Some days I hate this industry.

  • RPS (Score:5, Funny)

    by eldavojohn ( 898314 ) * <eldavojohn AT gmail DOT com> on Tuesday June 16, 2009 @09:08AM (#28346625) Journal

    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.

  • by Chrisq ( 894406 ) on Tuesday June 16, 2009 @09:15AM (#28346669)
    Actually it was crap. Not for nothing was it known as "The Turd Rock from the Sun"
    • 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 F

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

        • Re: (Score:3, Interesting)

          by idontgno ( 624372 )

          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 D

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


      • by fm6 ( 162816 ) on Tuesday June 16, 2009 @12:17PM (#28348807) Homepage Journal

        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.

        • 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.
          • by davecb ( 6526 ) *

            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 (;-))


            • 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 mak
          • by fm6 ( 162816 )

            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.

            • 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.
  • ... but paper beats rock... and scissors beats paper! Kiff, we have a conundrum!
  • by SailorSpork ( 1080153 ) on Tuesday June 16, 2009 @09:26AM (#28346763) Homepage

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

  • Um, Opteron? (Score:5, Insightful)

    by tjstork ( 137384 ) <todd DOT bandrowsky AT gmail DOT com> on Tuesday June 16, 2009 @09:27AM (#28346773) Homepage Journal

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

    • by Bigby ( 659157 )

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

    • Re: (Score:2, Interesting)

      by vil3nr0b ( 930195 )
      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.
      • by afidel ( 530433 )
        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.
    • 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...

    • by fm6 ( 162816 )

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

  • More likely reason (Score:5, Interesting)

    by downix ( 84795 ) on Tuesday June 16, 2009 @09:28AM (#28346783) Homepage

    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: (Score:3, Interesting)

      The Fujitsu SPARC64 VIIfx [] does look interesting, but does anyone know when it is actually supposed to be released?
    • by TheRaven64 ( 641858 ) on Tuesday June 16, 2009 @09:54AM (#28347013) Journal

      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.

      • 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.
        • by TheRaven64 ( 641858 ) on Tuesday June 16, 2009 @11:10AM (#28347847) Journal

          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: (Score:2, Insightful)

            by drinkypoo ( 153816 )

            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 SPA

            • by hairyfeet ( 841228 ) <bassbeast1968 AT gmail DOT com> on Tuesday June 16, 2009 @02:45PM (#28351447) Journal

              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.

            • 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: (Score:2, Insightful)

              by 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 co

            • 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

          • by Anonymous Coward on Tuesday June 16, 2009 @02:52PM (#28351573)

            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

  • by seeker_1us ( 1203072 ) on Tuesday June 16, 2009 @09:30AM (#28346811)
    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.
  • by mzito ( 5482 ) on Tuesday June 16, 2009 @09:36AM (#28346855) Homepage

    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: (Score:2, Insightful)

      by downix ( 84795 )

      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.

      • by mzito ( 5482 ) on Tuesday June 16, 2009 @10:32AM (#28347391) Homepage

        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.

      • by John Betonschaar ( 178617 ) on Tuesday June 16, 2009 @10:45AM (#28347543)

        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.

    • by peppepz ( 1311345 ) on Tuesday June 16, 2009 @10:49AM (#28347585)
      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.
      • by SEE ( 7681 )

        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.

    • 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.
    • by davecb ( 6526 ) *

      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.


  • by GreenTech11 ( 1471589 ) on Tuesday June 16, 2009 @09:39AM (#28346887)
    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

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

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

  • 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.
  • by paulsnx2 ( 453081 ) on Tuesday June 16, 2009 @10:08AM (#28347159)

    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 ( [] ) 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.

    • 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 (;-))


  • by segedunum ( 883035 ) on Tuesday June 16, 2009 @11:12AM (#28347865)
    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.
    • by davecb ( 6526 ) *

      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.


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

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

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

Have you ever noticed that the people who are always trying to tell you `there's a time for work and a time for play' never find the time for play?