Slashdot Mirror

← Back to Stories (view on slashdot.org)

Sun Kills Rock CPU, Says NYT Report

Posted by timothy on from the what-we-meant-was dept.

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

49 of 190 comments (clear)

  1. another one bites the dust! x86 uber alles! by Anonymous Coward · · Score: 2, Insightful

    Yuck.

    Some days I hate this industry.

  2. RPS by eldavojohn · · Score: 5, Funny

    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.

    --
    My work here is dung.
    1. Re:RPS by Ender_Stonebender · · Score: 2, Informative

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

      --
      Loose things are easy to lose. You're getting your hair cut. They're going there to see their aunt.
    2. Re:RPS by dkleinsc · · Score: 2, Funny

      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.

      --
      I am officially gone from /. Long live http://www.soylentnews.com/
    3. Re:RPS by moderatorrater · · Score: 4, Funny

      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.

    4. Re:RPS by Foodie · · Score: 3, Funny

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

  3. Actually it was crap by Chrisq · · Score: 5, Funny

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

  4. Re:That's just dynamite! by bluesatin · · Score: 2, Insightful

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

  5. Re:Very Interesting... by AdmiralXyz · · Score: 4, Funny

    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?

    --
    Dislike the Electoral College? Lobby your state to join the National Popular Vote Interstate Compact.
  6. IBM bought Sun? by characterZer0 · · Score: 4, Funny

    Oracle is gonna be pissed.

    --
    Go green: turn off your refrigerator.
  7. Sun kills Rock? by SailorSpork · · Score: 3, Funny

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

  8. Um, Opteron? by tjstork · · Score: 4, Insightful

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

    --
    This is my sig.
    1. Re:Um, Opteron? by vil3nr0b · · Score: 2, Interesting

      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.

  9. More likely reason by downix · · Score: 5, Interesting

    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.

    --
    Karma Whoring for Fun and Profit.
    1. Re:More likely reason by the+donner+party · · Score: 3, Interesting

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

    2. Re:More likely reason by TheRaven64 · · Score: 5, Insightful

      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.

      --
      I am TheRaven on Soylent News
    3. Re:More likely reason by TheRaven64 · · Score: 5, Interesting

      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.

      --
      I am TheRaven on Soylent News
    4. Re:More likely reason by hairyfeet · · Score: 3, Interesting

      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.

      --
      ACs don't waste your time replying, your posts are never seen by me.
    5. Re:More likely reason by Anonymous Coward · · Score: 5, Informative

      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

    6. Re:More likely reason by Anonymous Coward · · Score: 2, Insightful

      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.

  10. Wow, there's not much left then. by seeker_1us · · Score: 5, Interesting

    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.

    1. Re:Wow, there's not much left then. by Funk_dat69 · · Score: 5, Informative

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

      --
      FUNK!
  11. It doesn't really benefit IBM by mzito · · Score: 2, Interesting

    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.

    --
    me@mzi.to
    1. Re:It doesn't really benefit IBM by downix · · Score: 2, Insightful

      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.

      --
      Karma Whoring for Fun and Profit.
    2. Re:It doesn't really benefit IBM by mzito · · Score: 3, Insightful

      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.

      --
      me@mzi.to
    3. Re:It doesn't really benefit IBM by John+Betonschaar · · Score: 3, Insightful

      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.

    4. Re:It doesn't really benefit IBM by peppepz · · Score: 3, Interesting

      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.

  12. To summarise the article: by GreenTech11 · · Score: 3, Insightful
    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

    --
    Laughter is the best medicine, except if you have a broken rib.
  13. I'm sorry, what? by kurtmckee · · Score: 2, Funny

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

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

  14. Re:Very Interesting... by rodrigoandrade · · Score: 4, Funny

    Then Sun should give them negative feedback and move on.

  15. The summary is misleading.... by paulsnx2 · · Score: 5, Insightful

    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.

  16. Re:What are these architectures good for... by downix · · Score: 5, Insightful

    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.

    --
    Karma Whoring for Fun and Profit.
  17. Oracle will jettison the entire hardware division. by reporter · · Score: 3, Insightful
    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.

  18. Re:What are these architectures good for... by John+Betonschaar · · Score: 5, Insightful

    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.

  19. Re:What are these architectures good for... by afabbro · · Score: 5, Insightful

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

    --
    Advice: on VPS providers
  20. The whole *article* is misleading.... by davecb · · Score: 2, Informative

    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

    --
    davecb@spamcop.net
  21. Re:What are these architectures good for... by isj · · Score: 2, Informative

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

  22. This Was Always Going to Happen by segedunum · · Score: 5, Insightful

    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.

  23. Re:Oracle will jettison the entire hardware divisi by Just+Some+Guy · · Score: 3, Interesting

    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.

    --
    Dewey, what part of this looks like authorities should be involved?
  24. Re:What are these architectures good for... by segedunum · · Score: 2, Insightful

    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.

  25. Re:What are these architectures good for... by segedunum · · Score: 4, Insightful

    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.

  26. heat? by Anonymous Coward · · Score: 2, Insightful

    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.

  27. Re:What are these architectures good for... by Macka · · Score: 5, Insightful

    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.

       

  28. Re:So, basically,... by akadruid · · Score: 2, Informative

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

    --
    "Those who cast the votes decide nothing; those who count the votes decide everything." (attrib. Joseph Stalin)
  29. Re:Oracle will jettison the entire hardware divisi by idontgno · · Score: 2, Interesting

    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.

    --
    Welcome to the Panopticon. Used to be a prison, now it's your home.
  30. Re:Oracle will jettison the entire hardware divisi by fm6 · · Score: 3, Insightful

    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.

  31. Re:What are these architectures good for... by RubberDuckie · · Score: 2, Interesting

    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.

  32. Re:What are these architectures good for... by lewiscr · · Score: 4, Interesting

    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.

  33. Re:What are these architectures good for... by afidel · · Score: 2, Informative

    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.

    --
    There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.