Slashdot Mirror


Oracle To Halve Core Count In Next Sparc Processor

angry tapir writes "Oracle will halve the number of cores in its next Sparc processor and instead improve its single-thread performance, a weak area for the chip but one that's important for running large databases and back-end applications. The next Sparc chip on Oracle's roadmap, the T4, will have eight cores on each chip, down from 16 in the current Sparc T3."

200 comments

  1. ORE by Anonymous Coward · · Score: 1

    Oracle Ruins Everything

    1. Re:ORE by hairyfeet · · Score: 4, Insightful

      Uhhh...how EXACTLY is "Oracle ruining" anything at all? They are simply going to halve the cores and hopefully give single threads a serious kick in the ass. It is just as I said here when everyone thought Oracle was gonna kill SPARC and Solaris: Oracle is gonna offer a "top to bottom" IBM style stack, with a custom SPARC chip and a stripped down Solaris both optimized for running an Oracle DB with high throughput.

      Frankly I think it is a damned good business move and will probably make old Larry another mountain of money. It was pretty obvious that Sun with their flip flopping all over the place simply couldn't figure out how to make money with what they had, and old Larry took one look and figured he did. Considering how many enterprises run Oracle DB, and how PHBs like having only a single vendor to deal with, where is the bad? It is just business 101: buy a business that is floundering, get rid of the dead weight, and the revitalize the good parts. I have NO doubts that in three years or less Oracle will be THE DB to run in large and small enterprises, with a custom setup that will be easy to deploy and have incredible throughput. So where is the bad?

      --
      ACs don't waste your time replying, your posts are never seen by me.
    2. Re:ORE by dave87656 · · Score: 1

      We've found that since most transactions aren't cpu bound, increasing the number of cores, and, therefore the number of transactions which can be simultaneously processed, increased throughput, at least when you're talking about 700 connections (of which probably 100-200 are active). Would love to hear what others are experiencing.

    3. Re:ORE by vegiVamp · · Score: 2

      Well, someone at Oracle didn't quite get "it", I think: the T-series was very specifically designed with high parallelism in mind, and sacrificing some single-threaded performance for the purpose. The series was aimed and marketed specifically at applications that benefit more from threadcount than from pure mips. It got marketed at us like that, too, but we decided we needed more generic performance so we went for a different line of processors.

      And, before someone starts hawking about lintel, I'm talking M-5000 series and up, not desktops. Bring your hardware, and we'll do the famous Sun shotgun commercial. If it survives, we'll talk.

      --
      What a depressingly stupid machine.
    4. Re:ORE by Anonymous Coward · · Score: 0

      I really wish I could hurt you.

    5. Re:ORE by drinkypoo · · Score: 1

      Well, someone at Oracle didn't quite get "it", I think: the T-series was very specifically designed with high parallelism in mind, and sacrificing some single-threaded performance for the purpose.

      No, someone at Sun didn't quite get "it", which is why they scrubbed an entire architecture and then ended up with one based on old tech that had shit single-thread performance, much like intel going to the space heater Pentium IV and then going back to the Pentium III... which wouldn't do the same clock rates, and as such didn't have the same single-thread maximum performance (even though it was faster clock for clock) until the "Core" series, which also includes elements from the P4. Sun threw a ton of cores into it and claimed they had planned that all along, but they were lying. Oracle is fixing a serious problem... too late. And by "too late" I mean "after Sun was purchased by Oracle", because fuck Oracle. They are working on being the next IBM, and not even IBM wants to be IBM any more.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    6. Re:ORE by TheNinjaroach · · Score: 1

      we decided we needed more generic performance so we went for a different line of processors.

      So the T-series values highly parallel processing over generic performance. The anecdote you offer is that your company bought CPUs from someone else because you wanted more generic performance. Yet someone at Oracle "didn't quite get it" when they made the announcement to go after the kind of market that you're in?

      --
      I went to eat some animal crackers and the box said, "Do not eat if seal is broken." I opened the box and sure enough..
    7. Re:ORE by gstoddart · · Score: 1

      Oracle is gonna offer a "top to bottom" IBM style stack, with a custom SPARC chip and a stripped down Solaris both optimized for running an Oracle DB with high throughput.

      But, they're effectively ruining SPARC as a viable platform for anything other than an Oracle DB.

      From Oracle's position, it is good business. But, for everybody who has invested in Sun hardware, Oracle is more or less driving those companies to another platform, because suddenly those machines aren't really good for anything else.

      I have NO doubts that in three years or less Oracle will be THE DB to run in large and small enterprises, with a custom setup that will be easy to deploy and have incredible throughput. So where is the bad?

      Where is the bad?? Good god, you mean beside the bloated support contracts and needing 3-4x as many machines to do something as before? In my experience (limited, I admit), an Oracle install wants a small fleet of machines to do even a fairly smallish install of something.

      --
      Lost at C:>. Found at C.
    8. Re:ORE by gstoddart · · Score: 1

      Bring your hardware, and we'll do the famous Sun shotgun commercial. If it survives, we'll talk.

      Oh, someone please post a link to this ... I'm suddenly intrigued by this.

      --
      Lost at C:>. Found at C.
    9. Re:ORE by recharged95 · · Score: 1

      Or build a cloud-based stack and execute with pre-knowledge of where Google went wrong with the enterprise.

    10. Re:ORE by vegiVamp · · Score: 1

      It was still Sun then, and we still bought Sun, just not the T-series - for that particular project single-thread performance was more important.

      --
      What a depressingly stupid machine.
    11. Re:ORE by hairyfeet · · Score: 1

      Well what I think you are gonna see is for the "smallish installs" as you put it is an "Oracle cloud" where for a set price per month you have Oracle run the DB for you and end up with even small companies having an Amazon.com TPM throughput without the hardware hassles. And then for those that need on site or have the larger needs they will go the traditional route and set up on site Oracle/SPARC DBs.

      In case you didn't hear Oracle just set a new DB performance record using their custom set up, and I think this is the first advert of their future plans: An Oracle hosted DB cloud with totally insane TPM and six sigma uptime that you will just rent time on. as I have said here before old Larry didn't get rich as sin from not knowing how to get serious ROI from his purchases, and I think Sun will be the same and make Larry another mountain of money, despite what FLOSSies say.

      --
      ACs don't waste your time replying, your posts are never seen by me.
  2. and? by Pharmboy · · Score: 1, Interesting

    Not trying to be a smartass, but does it really even matter? Hasn't almost everyone already decided to move away from Sun/Oracle, excepting those with a tremendous investment in that area? Can their sales really do anything except go down on the hardware side? And reducing the number of cores can't help, as cores is now the buzzword, just like megahertz was back in the Pentium days. Even AMD had to fudge the model names back then to get people to buy the processors, which admittedly were faster per Mhz than Intel, but customers looked at raw numbers. I would think that cores would be the same, even with a more sophisticated buyer.

    --
    Tequila: It's not just for breakfast anymore!
    1. Re:and? by MightyMartian · · Score: 4, Insightful

      I don't think losing some grumpy OpenOffice and OpenSolaris users qualifies as "everyone has already decided to move away from Oracle". Java will be used for a long time to come, and has big time penetration in the enterprise world, as does Oracle's database offerings. And while I agree that "cores" is a buzz word, I'm not so sure at that level it's all down to the quality of marketing. We're talking very big customers who in a lot of cases have very specific needs, and tailoring your hardware to fit with the market your serving isn't a dumb thing to do.

      --
      The world's burning. Moped Jesus spotted on I50. Details at 11.
    2. Re:and? by Kjella · · Score: 1

      If everyone did as slashdot wanted, you wouldn't see much of .NET around either, but somehow I doubt slashdot commends the IT industry. The reality is that all the biggest software houses - Micrsoft, IBM, Oracle, SAP, CA etc. are an oligopoly, sure you may shuffle the users around a little as they move from one uncooperative money-hungry giant to the other but they don't leave. While PostgreSQL might be an okay alternative to just SQL Server or Oracle the database, they just don't deliver the whole range of tools and services. I know Oracle is now everyone's favorite hate object as they kill off the open source, but I doubt they're going away any time soon.

      --
      Live today, because you never know what tomorrow brings
    3. Re:and? by Pharmboy · · Score: 4, Interesting

      At the very least, Oracle has introduced a great deal of uncertainty into Sun products, so you have to ask "What does Sun hardware offer than other hardware doesn't?". With all the bad press, they have an uphill battle converting people to Sun from other platforms, and for those who have a choice, what *exactly* is the big benefit that can't be purchased from someone else for less? Obviously they will sell some product, (and yes, there is obviously some benefits to some customers, but not all) but I don't see how they are going to grow any new significant market share. There is a lot of options out there, and it isn't that expensive to throw a lot of cores at a problem. Any purchaser has to be wary and consider other options with a more open mind.

      The problem is that Oracle is *perceived* to not be that concerned about the Sparc platform, whether it is true or not. If the public (or at least the ones making the buying decisions) thinks that they will just be phasing it out or letting it die on the vine, it doesn't matter if it is true or not. I just think Oracle has done a terrible PR job during the whole Sun transition and it will bite them in the ass over the next few years. They certainly haven't made ANY new friends.

      --
      Tequila: It's not just for breakfast anymore!
    4. Re:and? by jedidiah · · Score: 1

      It's not that everyone has moved away from Oracle. They've moved away from "Sun/Oracle".

      You left a very important bit out.

      Even Oracle moved away from "Sun/Oracle".

      So this isn't just about disgruntled Star Office users.

      It's also about Oracle's core paying customers.

      --
      A Pirate and a Puritan look the same on a balance sheet.
    5. Re:and? by Anonymous Coward · · Score: 0

      There are two different markets. One that prefers less cores (i.e. less threads) but very good single threaded performance. One that prefers more cores (more threads) and does not care much about single threaded performance. Cores is not *the* buzzword that you make it out to be. There are two different markets and hence two different products,although both of them share the design. That is, essentially the same Sparc core but modifications to the SoC to get two different products.

    6. Re:and? by Doc+Ruby · · Score: 5, Informative

      No. Nobody's moving away from Oracle - that rhetorical question doesn't make you sound like a smartass, but rather its less intelligent opposite.

      What matters to Oracle's customers who buy Sun hardware is that their databases run as fast as possible, as that's the limiting factor on those customers' businesses. That's why Oracle bought Sun: to compete with IBM, which runs DB2 on IBM CPUs at the high end, the HW and SW tweaked to work best together for that operation.

      Reducing the number of cores isn't designed to help. It's designed to leave that amount of transistors on the CPU available for making Oracle DBs run as fast as possible in the few simultaneous threads that Oracle needs for DB performance.

      Oracle is not selling CPUs to the mass market that can't tell the difference among products, mostly because they don't have a benchmark that describes their use profile specifically. Oracle is selling to customers who pitch $:TPM to their bosses. And the $:TPM buzzword is not only not going out of style, it's what continues to drive $ to Oracle.

      --

      --
      make install -not war

    7. Re:and? by LWATCDR · · Score: 1

      They are selling to people that make choices based on hard numbers and not buzz words. Hopefully that is.
      There is still a market for big iron like IBMs Power and ZSystems as well as Sparc.

      --
      See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
    8. Re:and? by Anonymous Coward · · Score: 0

      Look kid, there's two things I love: Sparc and shaved pussy. So go back to playing with your pud.

    9. Re:and? by Tenser234 · · Score: 1

      US Government is actually investing more in Oracle now than before. Its become a "one stop shop". Servers, Linux, and DB all at one place.

    10. Re:and? by causality · · Score: 1, Insightful

      The reality is that all the biggest software houses - Micrsoft, IBM, Oracle, SAP, CA etc. are an oligopoly, sure you may shuffle the users around a little as they move from one uncooperative money-hungry giant to the other but they don't leave.

      That's because the industry is financially dominated by clueless customers who purchase what they do not really understand and do not wish to learn. This is true both in the case of corporate management (the techies don't usually make the purchasing decisions) and in the case of the "average consumer".

      but somehow I doubt slashdot commends the IT industry.

      Why not? It could use a little praise from time to time...

      --
      It is a miracle that curiosity survives formal education. - Einstein
    11. Re:and? by Lord+Byron+II · · Score: 1

      I think the OP was referring to Oracle's hardware offerings. Yes, Java, mySQL, and OpenOffice will be around for a long time.

    12. Re:and? by Anonymous Coward · · Score: 0

      Other than big installs, which means "already heavily invested in". Sun boxen has been trounced by generic intel boxen. When Sun machines are due to be replaced, they're not replaced with like. Oracle runs on linux, they're heavily involved in the kernel and sell their own. Why? Sun boxes are dead in the long term, just list IBM's mainframes and i-series. Over time, the applications are redone on must faster and significantly cheaper hardware, that's not tied to massive licenses.

    13. Re:and? by dogsbreath · · Score: 4, Interesting

      Not trying to be a smartass, but does it really even matter? Hasn't almost everyone already decided to move away from Sun/Oracle, excepting those with a tremendous investment in that area?

      I agree. That boat sailed about two years ago for us and we were a major Sun shop ( > 10,000 servers four years ago ). We are now almost exclusively VMware on Intel blades, mostly from IBM, or IBM P systems with IBM o/s. Vendors that were Solaris have moved to Linux. We briefly considered x86 Solaris but there was too much uncertainty with the on-again/off-again support for that platform.

      Oracle DB is still at the core of our internal corporate computing because of an excellent licensing deal but we use alternatives for consumer facing services.

      IMHO, the Sparc64 is hellishly expensive for the performance provided and the iron in the rack is heavy and power hungry. Nobody likes the M series servers. We don't like buying it, we don't like racking it, and we don't like what it does to our data center power distribution configuration.

      The T series are not badly priced and are excellent low power consumption web servers but suck at anything that is single threaded. Almost all application software is effectively single threaded: either there is an explicit single execution path or the app has attempted threading but the threads depend on a core path that is single threaded. Usually I can get a brand name Intel multicore box that provides 4x the execution performance at a lower cost, ... and with 3 yr onsite h/w service thrown in.

      Everything about Sun h/w is out of sync with what customers want.

      Oracle is almost clueless when it comes to hardware sales and development. Try "www.sun.com"... you get a redirect to the Oracle home page and then you have to search for a link to the server product lineup. It's almost as if they are hiding the fact that they have a hardware product to sell. I don't think the Oracle brain trust knows what to do with Sun h/w and the Solaris o/s.

      Oracle is a single core product software shop. That's their whole corporate culture and they don't really do other things well. What were they thinking when they bought Sun's h/w division? Possibly they could have just bought the rights to Solaris and developed it for the x86 h/w and made something of it. An argument could be made for the similarity between db and os development. But h/w? It's a black hole for Oracle. SPARC is dead. Write it off.

      Now if IBM had bought Sun and turned their R&D folk loose... there would have been hope for Solaris. Too bad so sad.

    14. Re:and? by guruevi · · Score: 1

      Sun's Sparc processors have a lot of cores which are great for large amounts of concurrent connections to either an (open source) database, file or webserver (as most of the open source designs spawn processes for a limited number of connections).

      I think Oracle is trying to compete with Sparc processors in an area Sparc processors were never designed for -- low-end server systems.

      Sparc is great with a well designed system and application underneath it and will beat the crap out of a 48U rack of x86 machines on those specific applications in only 6U worth of space. The cost however is heavy initially with the cheapest machinery coming in at ~$10k+ and easily going into the 100k+ for a full set.

      --
      Custom electronics and digital signage for your business: www.evcircuits.com
    15. Re:and? by Anonymous Coward · · Score: 0

      Not trying to be a smartass, but does it really even matter? Hasn't almost everyone already decided to move away from Sun/Oracle, excepting those with a tremendous investment in that area? Can their sales really do anything except go down on the hardware side?

      We're moving away Solaris (and SPARC) mostly because of support costs: there's only "premium" support, which is a four hour response. This is great for PRD, but we have many DEV, QA, and STG environments that don't need this level, and which is costly when you add it all up. If there was a 12x5 or 8x5 (or even warranty-only level), it wouldn't be a problem, it's just 24x7 for everything is too pricey for us.

      I've been using Linux since '96, BSD since about '98, and Solaris since about '00 (and Mac OS X since '03) and currently Solaris 10 is my favourite OS for servers (previously FreeBSD).

      As it stands you can spin up multiple zones on a system with 1% overhead and no hit on IOps. This is almost impossible until recently with any other system (VMware certainly has made great strides recently). Add in ZFS, DTrace, and Live Upgrade and you have systems that generally Just Work. I've never had to worry about live lock or the OOM with Solaris, where those things crop up time to time on Linux in my travels. And given the number of threads available on T-series CPUs, you can consolidate hosts 10:1 on a single piece of hardware without running into licensing fees about "virtual guests" like most other operating systems (especially handy for DEV and QA stuff).

      If Oracle simply changed some of the support options we'd be back on it in a second.

    16. Re:and? by Pharmboy · · Score: 1

      I understand what you are saying, but the question is why would someone invest in Sparc unless they are already committed to the platform? It would seem that IBM would be a safer choice, and very possibly more cost effective, if not clusters of more generic boxen. Google has the largest platform that I am aware of, and they have shown you can do it with clusters of otherwise commodity grade equipment. I don't think Facebook is running on Sparc either. Obviously enough are to keep them stamping out chips, but they weren't gaining market share even before Oracle bought them out.

      Again, those invested heavily in Sparc will continue for at least the short term, but that has to be a tough sale for a new startup system when there are ample choices, all which run the same core OS, Linux.

      --
      Tequila: It's not just for breakfast anymore!
    17. Re:and? by whoever57 · · Score: 1

      so you have to ask "What does Sun hardware offer than other hardware doesn't?"

      More cores. Oh, wait....

      --
      The real "Libtards" are the Libertarians!
    18. Re:and? by drolli · · Score: 2

      I rather think if they optimize the Sparc HW for databases it may a chance for the Architecture to survive in the long term. And no, nobody is going to switch because of ideology. They switch because of cost for running their applications. And no, such decicions are not made on the scale of 1-2 years, but a longer timescale.

    19. Re:and? by carnalforge · · Score: 1

      Talking as someone that worked indirectly for years for SUN, i feel sad. A lot of professional people with a fucked up management. After the Oracle deal the news were (FWIK) that every Solaris 10 and other software products like Sun's directory server, Sun cluster and others that before were paid only for support contracts that usually were included on hardware's price from 2011/01/01 will have to be licensed under a payment.
      And a lot of hardware lines are getting cut off, see SUN Fire series. Pretty nice machines. Ah, and for now nothing new about their storage products.
      Im noticing a lot of costumers from a year now, when they have to upgrade they move to vmware w redhat.
      Is it only me?

      --
      :wq!
    20. Re:and? by Anonymous Coward · · Score: 0

      You smart ass.

    21. Re:and? by dogsbreath · · Score: 3, Interesting

      I don't think losing some grumpy OpenOffice and OpenSolaris users qualifies as "everyone has already decided to move away from Oracle".

      The original statement was "Sun/Oracle" not "Oracle" and was referencing h/w sales.

      Four years ago, we (network/connectivity company) spent over $50 million annually on Sun servers (h/w only, support was on top of that). That is now almost zero. We still buy lots of servers but they are almost all x86 blades. Sun h/w just can't compete in any of the import aspects that affect h/w purchase decisions (performance, power consumption, stability, reliability, capital cost, support cost, TCO, lifetime cost, transition costs). Java is a non-issue and has nothing to do with server purchasing decisions. I know we are not alone in dropping Sun as a vendor.

      Note that we were a dyed-in-the-wool Sun/Solaris shop with a terrific core of dedicated Sun/Solaris admins. Nice thing about all that expertise is that, technically speaking, they had little trouble transferring their skill sets to other h/w and o/s platforms. Hardware and o/s vendors were happy to provide transition training. The cost of transition was a blip in our annual spend. Almost no one wants to go back even though Solaris is a superior o/s in many ways (io performance, network stack, scheduler, SMP).

      It will be interesting to see what Oracle reports on Sun h/w sales.

    22. Re:and? by MyLongNickName · · Score: 1

      If I moved to mySQL, what tool do they have to replace SQL Profiler?

      --
      See my journal for slashdot ID's by year. Mine created in 2005. http://slashdot.org/journal/289875/slashdot-ids-by-year
    23. Re:and? by PORNorART · · Score: 2

      "The problem is that Oracle is "perceived to not be that concerned about the Sparc platform"

      I don't know where people get that impression. Hasn't Oracle always been saying that their customers use Solaris/SPARC more than any other platform to deploy Oracle products on? This move makes sense in that regard as fewer faster cores are better to run Oracle's database on.

      Oracle bought sun to be able to deliver an end to end solution to it's customers and extract more revenue from them. A recent interview with McNealy indicated that Sun's lack of a DB solution allowed Oracle to get more revenue from Sun customers that Sun was hoping to retain. Combining the two companies that were already selling to the same customers reduces overhead and should increase profits.

      I just hope that Oracle doesn't try and limit their product range to only appeal to their base customers and instead try and expand that base. Though most of Oracle's customers will need both fast cores for the back end DBs and multi-threaded multi core systems for the front end application/web servers.

    24. Re:and? by Anonymous Coward · · Score: 0

      The usual answer to that is as follows: now you aren't paying for Oracle licenses, you can afford to throw hardware at all your performance problems and still save money.

      Of course, in practice you will still be paying for an expensive support contract, because big organisations literally can't use anything for free (which is on balance a good thing; e.g. it's why Red Hat is able to stay in business).

    25. Re:and? by Anonymous Coward · · Score: 2, Informative

      When I was on the job hunt, I saw exactly this. People took two paths:

      1: An exodus from SPARC hardware to x86 servers or blades, and a software exodus from Solaris to RedHat Linux or even Windows.

      2: A retooling and a move to IBM POWER6/POWER7 hardware. This hardware has VM support built in from the hardware up. In fact, dedicating a hardware box to a machine is passe, as opposed to having two VIO servers and a LPAR. (LPARs reboot extremely fast because it doesn't have to configure real-life hardware devices, in under than a minute, while a hardware IPL can take half an hour.) Oracle works decently on this environment and DB/2 can work with some SQL+ commands.

      What happened to the Sun that was awe-inspiring in colleges? Sun made a lot of groundbreaking items, from NFS, to NIS (not used these days, but a directory server is better than none), ZFS, zones, LDoms, etc. Now, it seems that Sun isn't a torchbearer when it comes to enterprise innovation, but just trying to market stuff.

      Software that allows machines to share RAM so box "A" can fetch something in box "B"'s RAM? That's pointless. Sun's enterprise solutions are starting to just not be competitive compared to what IBM can do at the midrange (Power Systems) or high end (zSeries), and what Intel/AMD can do at the low end.

    26. Re:and? by Haeleth · · Score: 1

      While PostgreSQL might be an okay alternative to just SQL Server or Oracle the database, they just don't deliver the whole range of tools and services.

      And there's one thing in particular they don't deliver: cost.

      Sure, if you switch to open source you might save your company a million dollars, but you can only do that once. Stick with Oracle and you can negotiate a million-dollar enterprise database contract every year! Much more impressive.

      Sadly I am not entirely sure I'm joking.

    27. Re:and? by dogsbreath · · Score: 1

      Solaris is a great o/s. Sun went from one weird CEO to another with no hope for redemption.

      When Adrian Cockroft jumped to eBay, you knew there was trouble in the henhouse. Hi tech company that undermined their core technology brain trust.

      Sad sad sad.

    28. Re:and? by Doc+Ruby · · Score: 2

      And that's why IBM is raking in ever more $BILLIONS in mainframe sales.

      You and the post you're defending are like a press release from 1989.

      --

      --
      make install -not war

    29. Re:and? by dogsbreath · · Score: 1

      Yup and Yup. You got it exactly. That's what we did and that's what our competition has done.

      Spot on.

    30. Re:and? by rubies · · Score: 1

      Alternative timeline: Sun should have seen the writing on the wall when NetBSD and Linux started to get popular in the early nineties. Why? Because a lot of us ex-Sun jockeys really, really wanted a Sun at home but just couldn't afford to run even a second hand IPX workstation when a PC was so cheap. Sure the PC was a piece of junk, but loaded up with X windows and all the Gnu tools, you could get most of your support scripts working from home and started not worrying so much about having a Sun.

      If they'd have looked downwards to their primary users instead of trying to capture the enterprise market and seen what was happening, they'd have shipped a free Solaris x86 that worked with commodity hardware rather than a narrow (expensive, hard to find) subset and Linux wouldn't have gone anywhere.

    31. Re:and? by ToasterMonkey · · Score: 1

      Even AMD had to fudge the model names back then to get people to buy the processors, which admittedly were faster per Mhz than Intel, but customers looked at raw numbers. I would think that cores would be the same, even with a more sophisticated buyer.

      Really? cores == cores? You say this on an article about a line of processors with a bazillion hardware threads. No doubt computer buyers often don't understand what they're getting, but to a person that naive, a T3 has 128 processors. Have fun debating processor vs. core with a core == core luddite, not to mention this processor line is a SoC with four way SMP, four memory channels, PCI-e, and dual 10gbit nics. /sigh.. it's just one chip though, and my gaming rig has two, so it's twice as fast. Hopefully those people don't have jobs requiring them to make complex decisions.

    32. Re:and? by afidel · · Score: 1

      Because DB2 is less universally supported by LOB apps than Oracle. You are right that Linux on x86 has been eating a big part of all the traditional Unix vendors lunch. It might not be good enough for the top 1% of shops but for the other 99% that used to make up a large market for those vendors they've priced themselves out of the market and their corporate culture is a turnoff to a lot of folks. Heck even 4 years ago when we were looking at platforms for our ERP system they weren't really competitive (IBM was almost 3x more expensive than the next most expensive system when we asked for a box with more than a couple PCI-X slots) and Sun's 5 year cost was almost 2x that of the HP AMD system due to support contracts costing over 20% of purchase price per year vs 15% total for the HP open solution. I have no reason to think that Sun solutions have gotten any cheaper under Oracle.

      --
      There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
    33. Re:and? by ToasterMonkey · · Score: 1

      Oracle DB is still at the core of our internal corporate computing because of an excellent licensing deal but we use alternatives for consumer facing services. ...
      Everything about Sun h/w is out of sync with what customers want.

      Oracle is almost clueless when it comes to hardware sales and development. Try "www.sun.com"... you get a redirect to the Oracle home page and then you have to search for a link to the server product lineup. It's almost as if they are hiding the fact that they have a hardware product to sell. I don't think the Oracle brain trust knows what to do with Sun h/w and the Solaris o/s.

      That's unfair, go to any gigantic company's site. EMC, IBM, HP, GE, Hitachi. These are mega corporations, not storage, hardware, computer, jet, wild guess, etc.

    34. Re:and? by bill_mcgonigle · · Score: 1

      Gosh, somebody who really gets it. Sorry, no mod points today.

      --
      My God, it's Full of Source!
      OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
    35. Re:and? by Anonymous Coward · · Score: 0

      Why do so many retarden like to use "-en" to pluralise their worden? "-(e)s" all the way!

      Boxes boxes boxes.

    36. Re:and? by dogsbreath · · Score: 1

      Sun needed heavy investment and lots of R&D to continue to compete in the h/w arena. They didn't have it and Fujitsu was no help. IBM, Intel and AMD poured tons of $$$ into chip development while Sun kept missing release dates. While Intel and IBM developed high-density fabrication methods with remarkable decreases in execution cycle times, Sun was stuck with technology that was rapidly being left behind.

      On the o/s side, Solaris is a great stand-alone o/s but Sun almost totally missed the transition to virtualization. Their moves in that area have been too little and too late, just like the h/w development side. IBM's P systems and VMware on Intel are so advanced in terms of flexibility and functionality that it isn't funny.

      A lot of Sun customers stuck around when they should have been moving on to competing products. Sun had lots of opportunity to fix things but they never delivered.

      Sun's executive just milked their cash cows (large unix/solaris shops) until one day the herd dried up. They were lucky to find a buyer for the company.

    37. Re:and? by afidel · · Score: 1

      Heck look at what open systems can do, HP DL980 can scale to the same CPU performance and half the ram of the M9000 and a fully decked DL980 (64 core, 128 thread and 2TB of ram with 4x 8Gb FC ports, 2x QDR Infiniband and 4x 10Gbe ports) costs $233k with 5 years of 6 hour call to repair support where the M9000 starts at twice that for a very underpowered config and doesn't include the ~20% per year maintenance.

      --
      There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
    38. Re:and? by Anonymous Coward · · Score: 0

      No stupid Those of us who are doing heavy duty numerical work still prefer the faster Ultrasparc to x86. Using Solaris 10u8, SunStudio 12 compilers WRFV3.1 One Ultrasparc-IV+ at 1.35gHz outperforms a 2.4gHz quad-core Intel

    39. Re:and? by carnalforge · · Score: 1

      Solaris is a great OS and you're right on the CEO part.
      Too bad they didnt GPL'd their SO before getting sold.
      I'll miss their HW/SW stack. Sad for this.

      Though linux is getting confortable now.

      --
      :wq!
    40. Re:and? by DiegoBravo · · Score: 1
    41. Re:and? by MyLongNickName · · Score: 0

      That tool is nothing like SQL Profiler. I have used it and the query profiler is sorely lacking and does not (as far as I could find) give you the ability to see queries hitting your db in real time.

      Have you ever used SQL Profiler?

      --
      See my journal for slashdot ID's by year. Mine created in 2005. http://slashdot.org/journal/289875/slashdot-ids-by-year
    42. Re:and? by dogsbreath · · Score: 1

      M servers are ugly no matter how you look at them. We had a network h/w vendor whose management app only runs on Solaris and is only certified for the M series. We bought the freakin' h/w but everyone hates it. The worst thing is if you need support you get an idiot from a contracted office IT support company (name left out to protect the incompetent). These guys are used to office PCs and printers and have no clue about 7x24 services and have little experience with the h/w they support. They are always on the phone to Sun for advice.

    43. Re:and? by MyLongNickName · · Score: 2

      Actually, this isn't as far off as I first thought. It lacks a lot of the bells and whistles I am used to... I don't see filtering capabilities and I don't see real time monitoring, but it is a lot better than what I was using a couple years ago. I might have to give this another look.

      Thanks.

      --
      See my journal for slashdot ID's by year. Mine created in 2005. http://slashdot.org/journal/289875/slashdot-ids-by-year
    44. Re:and? by causality · · Score: 1

      If I moved to mySQL, what tool do they have to replace SQL Profiler?

      I believe you missed my point. The bigger question is: why should it be difficult to find a truly good replacement when there is such demand for this kind of useful tool?

      Why, it's almost as though a few major players have extreme dominance of this market and can get away with that because many of their customers are not tech-savvy.

      That's what my previous post was addressing.

      --
      It is a miracle that curiosity survives formal education. - Einstein
    45. Re:and? by carnalforge · · Score: 2

      No. Nobody's moving away from Oracle - that rhetorical question doesn't make you sound like a smartass, but rather its less intelligent opposite.

      What matters to Oracle's customers who buy Sun hardware is that their databases run as fast as possible, as that's the limiting factor on those customers' businesses.

      Bullshit. Who is buying SUN hardware anymore after their buyout? And after Oracle changed prices on the OS?

      That's why Oracle bought Sun: to compete with IBM, which runs DB2 on IBM CPUs at the high end, the HW and SW tweaked to work best together for that operation.

      Maybe I'm young, or whatever, but in all the "big enterprise costumers" where i've been working i've never ever seen a DB2. I have seen in order of frequency: Oracle DB from ~8 to 11r1 then Sybase. On this operating systems, in order of frequency: Solaris, HPUX, Linux, AIX.
      All of them had a DB supporting SAP BTW, and there i think Oracle is pointing.

      Reducing the number of cores isn't designed to help. It's designed to leave that amount of transistors on the CPU available for making Oracle DBs run as fast as possible in the few simultaneous threads that Oracle needs for DB performance.

      As I'm not a DBA i cant say much on that. Though i remember a performance problem related on what you're saying. But it turned out the DBA was doing an import of a huge DB with AUTOCOMIT=1.

      Oracle is not selling CPUs to the mass market that can't tell the difference among products, mostly because they don't have a benchmark that describes their use profile specifically. Oracle is selling to customers who pitch $:TPM to their bosses. And the $:TPM buzzword is not only not going out of style, it's what continues to drive $ to Oracle.

      --
      :wq!
    46. Re:and? by The+End+Of+Days · · Score: 0

      No, it's not the case that only the people who find your preferred solution compelling are smart. Sorry.

    47. Re:and? by cthulhu11 · · Score: 1

      Sun hardware offers a usable serial console, even on x86 boxes. HP sure doesn't and I suspect that few or no others do.

    48. Re:and? by seeker_1us · · Score: 1
      People who buy Sparcs aren't looking for buzzwords. They have to get the best performing platform for their money because their job depends on it, and they aren't stupid sheep.

      And reducing the number of cores can't help, as cores is now the buzzword, just like megahertz was back in the Pentium days.

    49. Re:and? by LWATCDR · · Score: 1

      Well not all apps scale well to clusters. Things like billing apps are a good example. For anything involving money you want and ACID data base. If Facebook forgets a few thousand status updates or if they don't show up on some friends wall it isn't a big deal. If a few thousand credit card transactions don't make it into the system....
      That is why you Power, Sparc, and ZSystems are still in use.

      --
      See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
    50. Re:and? by zaphirplane · · Score: 1

      No. Nobody's moving away from Oracle - that rhetorical question doesn't make you sound like a smartass, but rather its less intelligent opposite.

      That would be a dumbAss, right ? where's my cookie

    51. Re:and? by zaphirplane · · Score: 2

      relax dude, why are all your posten so serious

    52. Re:and? by Anonymous Coward · · Score: 0

      I don't know if people are moving away from Oracle , but what I'm seeing at companies ( I'm a consultant ) is that people like to have the IBM stuff for Tier 1 and perhaps SQL Server on Intel for Midrange databases.

    53. Re:and? by box2 · · Score: 1

      Throwing more cores at a problem for cheap is exactly the kind of solution they are not providing with the T4. They are solving a very different problem where each threads performance needs to be maximized and I applaud them for the effort. We run a big replication tree of MySQL servers and it seems like every day we are trying to figure out new ways to offload as much as we can to new groups of servers. I look forward to some serious overhaul in per-thread CPU performance (and synergy with MySQL core) as this will decrease individual query time whereas multiple threads would help only in query concurrency. Also for applications like haproxy which are single-threaded specifically for quantifiable performance reasons, this type of push will be much appreciated. If I had to chose development towards a problem that is not getting enough attention and impressing people with "more cores and ghz", I chose the problem solving solution. Thankfully they are not marketing their server-grade hardware to same people who need the iPhone with the bigger geebeez. At least I hope not. It pains me to hear the masses cry murder about how everything Oracle sucks, and everyone in the company is an idiot too. Like how we saw all the people saying the developers of Hudson should branch away for barely even a misunderstanding between Oracle management and the devs. How over-hyped was that? So many people popping in to contribute "Stick it to that bastard Ellis!" and then leaving. If you've worked a decent amount of time with other people, you've probably been witness to how many developers don't exactly agree amongst themselves. Also, branching is not a solution to the problem of "We need to find a reliable place to host our project." and splitting the existing community is the worst possible thing you could be do for the project. The whole situation reminds me of my friend who worked alongside us every day for years and one day was promoted to manager. Before this day, it was easy for my co-workers to say things like "Hey, don't store pictures in the database. The filesystem will handle it much better." After he was promoted to manager they would just keep to themselves and mock him for doing a bad job. It's childish and stupid. But in reality for Oracle, aside from the mass exodus of sun developers, keeping a tight lip on plans for the future, and possibly re-branding splash pages as a first priority, I can't blame Oracle for a whole lot. Any transition of this size will be difficult and probably suck for a long time, but at least let Oracle play their cards before becoming another fanboy of hate.

    54. Re:and? by Splab · · Score: 2

      You make absolutely no sense.

      People using Oracle will be buying SUN hardware in their next upgrade, it's what Oracle says they must use, it will be what they are using - that's the whole point of buying Oracle, they take the blame if it doesn't work, but you *must* buy their medicine.

      If we are using emperical evidence, I would make the claim that no one is using Oracle in corporations, because I've never seen anyone use it when working for mega corps. I have however seen MySQL, DB2 and MSSQL - but unlike you I'm very well aware that it makes no sense to make such claim.

      And your last comment about DBA - again, you make no sense. Why was an entire DB being imported on a live environment? Would you rather have had a single commit in the end? If this was such a "huge DB" (I'm thinking TB when talking huge), he might only have had the option of a single commit or autocommit; in which case autocommitting is the correct option, since the rollback tree for a TB class DB would destroy everything.

    55. Re:and? by Anonymous Coward · · Score: 0

      That's unfair, go to any gigantic company's site. EMC, IBM, HP, GE, Hitachi. These are mega corporations, not storage, hardware, computer, jet, wild guess, etc.

      While large, Orcale is still a one trick pony. Unless they change their attitude and it seems they won't.

    56. Re:and? by k8to · · Score: 1

      The niche is narrower than you suggest. Current sparc procesors are great for highly transactional systems that are low on computation. This means databases which are really acting as fancy smart datastores for various applications.

      Certainly that's how databases were traditionally originally considered, but it's pretty common these days for database loads to include computational demands, which don't really fly on Sparc.

      Meanwhile a lot of other loads are really foolishly parallelisable, so datasets with low associativity are going parallel on cheap hardware.

      If you still have a high asssociativity noncomputational database load, sure, sparc may be a good bet, especially if the load is too larger for smaller boxes, and if you trust oracle's offerings more than HP's or IBM's.

      --
      -josh
    57. Re:and? by dogsbreath · · Score: 2

      Sun's Sparc processors have a lot of cores which are great for large amounts of concurrent connections to either an (open source) database, file or webserver (as most of the open source designs spawn processes for a limited number of connections).

      The T series are great web servers. As a db server, your mileage will vary and usually the result is not that great. Application servers also don't fare well on the T systems. Problem is that the T servers are great if you can run multiple instances of the same thing, or if the app is truly multi-threaded. In practice, multi-threaded apps are almost non-existant. Well, at least the apps that you want to run on Solaris are problematic.

      Sparc is great with a well designed system and application underneath it and will beat the crap out of a 48U rack of x86 machines on those specific applications in only 6U worth of space. The cost however is heavy initially with the cheapest machinery coming in at ~$10k+ and easily going into the 100k+ for a full set.

      Horsefeathers.

      Maybe back in Y2K that was true but not now. In comparison with the M servers, in the same amount of rack space, Intel based servers provide better performance with a lower power draw, lower capital cost, and lower floor load (weight).

      eg: M5000 with 4 quad core SPARC cpus @ 2.5 GHz will take 10 RU of space, draws well over 4 Kw (!) of power, weighs in at 275 lbs (!!!) and lists at $81,000. Oh, and the pig is about 31" deep which throws my rack cable design all to hell. Two healthy guys and a rack lift are mandatory for installation.

      A Dell R900 with 4 quad core Xeon cpus @ 2.93 GHz is 4 RU of space, draws just over 1 Kw of power, and weighs 92 lbs. List is about $22,000 and it is only 27" deep. If you don't like Dell, similar systems can be found through IBM or HP.

      Our internal testing puts the Dell well ahead of the M server for performance with our apps. Plus I can run VMware on the Dell. In particular, Oracle RAC performs very well on the Xeons as compared to the M 5000.

      We used to see a performance advantage to the SPARC RISC architecture over the Intel but that was a long time ago. There is still an SMP advantage to Solaris but the instances where that advantage shows are few.

    58. Re:and? by k8to · · Score: 1

      The niche is narrower than you suggest. Current sparc procesors are great for highly transactional systems that are low on computation. This means databases which are really acting as fancy smart datastores for various applications.

      Certainly that's how databases were traditionally originally considered, but it's pretty common these days for database loads to include computational demands, which don't really fly on Sparc.

      Meanwhile a lot of other loads are really foolishly parallelisable, so datasets with low associativity are going parallel on cheap hardware.

      If you still have a high asssociativity noncomputational database load, sure, sparc may be a good bet, especially if the load is too larger for smaller boxes, and if you trust oracle's offerings more than HP's or IBM's.

      --
      -josh
    59. Re:and? by carnalforge · · Score: 1

      You make absolutely no sense.

      People using Oracle will be buying SUN hardware in their next upgrade, it's what Oracle says they must use, it will be what they are using - that's the whole point of buying Oracle, they take the blame if it doesn't work, but you *must* buy their medicine.

      Oracle says that linux is fine, and each and every release of redhat is supported. That is what i am seeing. Sure, you buy the DB, no escape from that.
      But hey you genius, tell me, where are Oracle advertising "their" hardware? I must be missing something.

      If we are using emperical evidence, I would make the claim that no one is using Oracle in corporations, because I've never seen anyone use it when working for mega corps. I have however seen MySQL, DB2 and MSSQL - but unlike you I'm very well aware that it makes no sense to make such claim.

      Cool down, i was just saying what i see around. Nice to see there are other setups around, indeed, i'm glad for this, i'm not a fan of Oracle.

      And your last comment about DBA - again, you make no sense. Why was an entire DB being imported on a live environment? Would you rather have had a single commit in the end? If this was such a "huge DB" (I'm thinking TB when talking huge), he might only have had the option of a single commit or autocommit; in which case autocommitting is the correct option, since the rollback tree for a TB class DB would destroy everything.

      Where did i said it was a live environment? Where did you got it? Talking about an import?
      You seem to have a nice crystal ball.

      --
      :wq!
    60. Re:and? by dgriff · · Score: 1

      Almost all application software is effectively single threaded: either there is an explicit single execution path or the app has attempted threading but the threads depend on a core path that is single threaded.

      That's quite a bizarre claim. I've looked at hundreds of Java dumps from hundreds of different customers and the vast majority are doing multithreading on a massive scale with no issues. If there is contention it's usually pretty obvious from the dump.

      I can only assume that your company's software is quite poorly designed from a threading perspective.

    61. Re:and? by mwvdlee · · Score: 1

      It's probably all down to economics.

      How much would it cost to purchase an SQL profiler, supporting it and paying people to work with it.

      And how much would it cost to simply add another CPU or database node?

      --
      Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
    62. Re:and? by mwvdlee · · Score: 1

      U R _so_ not 1337!!!1!!12!

      --
      Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
    63. Re:and? by xnpu · · Score: 1

      Oracle has never been very interested in small business, who are the only ones potentially walking away here. Big business knows what Oracle can do for them and knows how to sign a proper contract with all the guarantees they need. I dare argue that most of these bigger clients care more about keeping Oracle on board than they care about a particular hardware brand. Oracle may in fact switch a number of big boys to Sparc who wouldn't have used it otherwise.

    64. Re:and? by Viol8 · · Score: 1

      I was in the same situation as you. I wanted a sparc machine at home for work related and development use back in the 90s but I just couldn't justify (or frankly at the time afford) one. Linux wasn't really up to much at the time but it was better than nothing (or windows) so I got a cheap PC , shoved slackware on it and never looked back.

      If Sun has priced their desktop systems realistically it might not in the long run have saved them but it certainly might have helped in some small way. Charging 10K for a sparc workstation that had performance that you could achive with a 2K PC was just hubris and the worst kind of corporate reality denial. And the buggers charged extra for a keyboard and Monitor! For a workstation?? Wtf?!

    65. Re:and? by lanc · · Score: 3, Informative

      first of all, you can put 8 quadcore CPUs at 2.66GHz in an M5000.
      You can even create two domains on the box that act like two separate machines, if you need electrical separation or want to build HA in-a-box. You can replace HW on-the-fly in the M5000. You can put more than 256GB RAM into it, if you want to. You can set up RAM mirroring in case you needed it. We are talking here real enterprise features, not just raw mips.

      Anyways, we are comparing here apples to oranges, sparc to x86. If your platform decision goes towards x86, then go for it. In this case, however I would definitely consider the SF X4470 or the X4800 servers if you need raw power. Or an Exadata if you need pretuned, preconfigured RAC on X86 - there you will find the X4800s as well :)

      --
      "First they ignore you, then they laugh at you, then they attack you, then you win." -- Mahatma Gandhi
    66. Re:and? by segedunum · · Score: 1

      I don't think losing some grumpy OpenOffice and OpenSolaris users qualifies as "everyone has already decided to move away from Oracle". Java will be used for a long time to come, and has big time penetration in the enterprise world, as does Oracle's database offerings.

      Seriously, who mods this crap insightful?

      In case you didn't get the memo then the OP said Sun/Oracle, and over the past ten years Sun slowly went bust because Solaris and SPARC users jumped ship to x86 and Linux systems, in particular. Oracle stated that Sun were even losing $100 million per month. If they're running Java they're running it there. Oracle database have been run successfully for a very long time on such systems, and a lot of those customers have already jumped ship. It's going to be a tall order for Oracle to convince them to go back.

    67. Re:and? by segedunum · · Score: 1

      No. Nobody's moving away from Oracle - that rhetorical question doesn't make you sound like a smartass, but rather its less intelligent opposite.

      It would help if you could actually read. He said Sun/Oracle, which clearly means the old Sun and new business Oracle is now running, not that people are moving off Oracle databases en masse.

      What matters to Oracle's customers who buy Sun hardware is that their databases run as fast as possible, as that's the limiting factor on those customers' businesses.

      They're already doing that and have done for some time, and many have done it by migrating off Sun hardware and software. That's why Sun got bought out.

      Reducing the number of cores isn't designed to help. It's designed to leave that amount of transistors on the CPU available for making Oracle DBs run as fast as possible in the few simultaneous threads that Oracle needs for DB performance.

      People have solved single threaded performance over the past ten years by moving to x86, hence the current dire state of Sun's hardware business. IBM operates in a different realm of mainframes that Sun doesn't have. Sun's business has crossed over far too much with the commodity hardware and software that's been available for some time.

    68. Re:and? by drinkypoo · · Score: 1

      People have been moving away from Sun since time was time. I got my first sysadmin job because of my Linux/x86 experience and because I had at least seen SunOS before, and I was hired into a fully-Sun shop which wanted to start rolling out x86 PCs to desktops... which I did. I could deploy two PCs with 20" monitors for the price of a single used SS2, which was the "nice" machine on the user desktop, we still had 1s and 1+s in service.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    69. Re:and? by drinkypoo · · Score: 1

      IBM is raking in billions in sales of x86 clusters running Linux and of POWER-based mainframes running Linux. I have been hearing more and more nerds pitching DB2, which means Oracle must have finally crufted itself beyond IBM.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    70. Re:and? by segedunum · · Score: 1

      And that's why IBM is raking in ever more $BILLIONS in mainframe sales.

      You and the post you're defending are like a press release from 1989.

      Sun does not have an IBM mainframe competitor. Their hardware and software sales have crossed over heavily with x86 and then Linux resulting in their lunch being seriously eaten. If anyone thinks Sun and Oracle are going to compete with IBM then they're going to be very disappointed.

      Replacing IBM mainframes was a Sun press release 1989. Unfortunately, not only were they squeezed from the bottom up by more powerful hardware and capable software, the high-end mainframe sector where IBM live that they so derided at one time and that would have largely insulated them is something they're not a part of. Given that mainframes tend to continue to exist for historical application and code and inertia reasons Oracle/Sun are going to find it totally impossible to break into there now.

    71. Re:and? by segedunum · · Score: 1

      You make absolutely no sense.

      People using Oracle will be buying SUN hardware in their next upgrade, it's what Oracle says they must use, it will be what they are using - that's the whole point of buying Oracle, they take the blame if it doesn't work, but you *must* buy their medicine.

      No, they won't be buying it if they don't want it. That makes no sense whatsoever, unless what you appear to be saying is that Oracle will have to force hardware that many will see as inferior on to people? I'm afraid that's not a winning strategy.

      As the OP says, people have been doing that and dumping Sun hardware and software for years. If that wasn't the case then they wouldn't have got bought by Oracle and wouldn't have been losing $100 million per month as they have been doing. That's the material point.

    72. Re:and? by hal2814 · · Score: 1

      I worked in sales for a Sun competitor for a while. When SGI was having troubles, we did a marketing campaign targeting SGI customers that was massively successful so when Sun was bought out we jumped on it, too. It was no SGI campaign, but a lot of enterprise-level customers were very interested in what we had to say. Our sales in the Sun campaign were twice what we were getting in our other targeted campaigns, but we burnt up a lot of time on the phone compared to the others. I don't think everybody has already decided to abandon Sun/Oracle, but if I were Oracle, I'd be a bit concerned that companies who would never in the past have talked to us are talking to us now.

    73. Re:and? by lanc · · Score: 1

      Oracle is almost clueless when it comes to hardware sales and development. Try "www.sun.com"... you get a redirect to the Oracle home page and then you have to search for a link to the server product lineup. It's almost as if they are hiding the fact that they have a hardware product to sell. I don't think the Oracle brain trust knows what to do with Sun h/w and the Solaris o/s.

      I beg to differ. sun.com is being redirected to oracle.com, but there right on the front page there is a complete section called 'Server and Storage Systems'.
      Also, their pre-Sun HW product, the Exadata, is being updated with new Sun HW and Solaris. Solaris 11, the first major release released under the Oracle regime.

      And last but not least have a look at their T-CPU roadmap - they have released the T3, and are working on the T4 to eliminate the single-thread performance weakness of the series. That is, doubling the efforts in the release cycle, in comparison to Sun's T1 and T2 releases (not to mention the Rock).

      Please reconsider your views. Would Oracle have named their new product "SPARC Solaris Sunrise Supercluster" if they'd plan to invest in both Sparc and Solaris?

      --
      "First they ignore you, then they laugh at you, then they attack you, then you win." -- Mahatma Gandhi
    74. Re:and? by Lonewolf666 · · Score: 1

      Sun's Sparc processors have a lot of cores which are great for large amounts of concurrent connections to either an (open source) database, file or webserver (as most of the open source designs spawn processes for a limited number of connections).

      I think Oracle is trying to compete with Sparc processors in an area Sparc processors were never designed for -- low-end server systems.

      My guess is Oracle(the company) wants to optimize for Oracle(the RDBMS). Assuming the /. article in correct in claiming single thread performance is important for databases. Either way, this puts them into more direct competition with Intel's and AMD's x86 machines:

      - currently up to 6 cores for Intel ("Westmere")
      - and up to 12 cores for AMD ("Magny-Cours")

      We'll see how well this works - I have my doubts....

      --
      C - the footgun of programming languages
    75. Re:and? by segedunum · · Score: 1

      Sun needed heavy investment and lots of R&D to continue to compete in the h/w arena. They didn't have it and Fujitsu was no help. IBM, Intel and AMD poured tons of $$$ into chip development while Sun kept missing release dates.

      Indeed. It takes a ton of investment to keep a hardware business going, and the more customers Sun lost the less investment they could put in. They've clearly been struggling since the 90s when their workstation business disappeared overnight, and a few years later when those companies who laid out money on Sun to run web systems realised they could get more power for less money when they upgraded. Time was of the essence, and as far as I could see since the early 00s Sun spent their time convinced of their own superiority and that customers would simply come back to them because that's what Sun believed. Wishful thinking, in other words. I've lost count of the number of times a Sun representative tried to tell me that you couldn't run anything 'serious' on a Linux and x86 system, despite what the last decade has taught us.

      IBM were largely insulated from that bottom-up squeeze from x86 systems because they had the resources to put the investment into their hardware and their high-end mainframe business is simply in a different arena. That was not the case with Sun. They were trying to get people to move away from mainframes to them for years and yet it is ironic that it is the thing that would have saved them had they got involved much, much sooner.

      They were lucky to find a buyer for the company.

      You're right there. One wonders why IBM turned tail when they were looking to buying them, because surely they were only going to buy Sun for the customer list? Oracle are going to be pulling their hair out absorbing Sun's current significant losses while trying to turn the ship around. I can't see it being possible because I don't know what Sun's market is now. You wouldn't go to them for a mainframe but the stuff they do sell has long since been outperformed and can be done faster and cheaper elsewhere.

    76. Re:and? by FictionPimp · · Score: 1

      How about losing a large segment of the community college market? We used to buy a half dozen servers ever year from sun to replace our existing equipment. Then oracle dropped the matching grant program for edu and we have already decided this year will be the year we move everything to intel/linux. Speaking with other people in the sector, I can't say we are alone.

    77. Re:and? by John+Betonschaar · · Score: 1

      Wait, what? You're kidding, right?

      We run simulations that are numerically intensive on SPARC, which are developed and tested on x86. We recently did some extensive benchmarking since the machines in the field (sold to customers) with Sun hardware in there were hitting real-time constraints in computation time, while our run-of-the-mill C2D and Xeon workstations were not even close to hitting any performance constraints. The 8-core M3000 was up to three times slower than a $500 C2D developer laptop, and up to TEN TIMES slower than a quad-core Xeon at 2.5 Ghz. We're talking about parallelized computations (ie: the Xeon shows around 3x speedup compared to running the same code single-threaded) that are almost completely FPU and memory-bound, ie: the typical 'heavy duty numerical work' case. If there's ONE area where SPARC hardware sucks so much it hurts, it's performance in FPU-intensive code.

    78. Re:and? by dogsbreath · · Score: 1

      Been there, done that and suffered. Too many out of the box h/w failures from Sun; poor support for h/w; late delivery of h/w; driver problems.... the list goes on. M series are data center pigs (power, space, weight) and for any given configuration I can get a better configuration elsewhere for a hell of a lot less capital cost and operating expense. As far as Intel based Sun h/w, we have tried that as well but again, competitors deliver product that is better supported, cheaper, and more reliable. Plus Sun always does something quirky, whether it is another LOM flavor or some weird driver that has to be loaded before you can run Win server.

      Hey, I am a Solaris guy back to 2.5 and a big champion of the o/s. I used to love their h/w but truth is there is better performance, better reliability, better cost effectiveness down another path.

    79. Re:and? by Anonymous Coward · · Score: 0

      My bad... I tried the URL before I made the comment and I landed on a page with no Sun info. Possibly the perils of autocomplete in the address bar.

      Much shame.

      Thanks for the correction but I'll stand by my feelings re: Sun h/w and Oracle's ability to turn the ship around. We went from over $50 million/year on Sun h/w to zero in four years. I know our competitors have done the same and we are a relatively small outfit. IBM has most of our business now and I cannot imagine what would make us go back to Sun h/w. Sun is behind on performance, data center footprint, virtualization, cost, reliability, and ability to deliver. If they picked one area to focus on then I could possibly see some light for them. My choice would be o/s and virtualization. Make it work better at a lower cost on Intel and IBM platforms. Give special pricing for Oracle/Solaris combos, whether the DB is on the Solaris o/s or not. Make Solaris the performance and security choice for Oracle installations.

      Forget the server h/w development. Just rebrand what someone else makes so that there are sales bundling possibilities.

    80. Re:and? by TheRaven64 · · Score: 1

      No one will buy SPARC. No one will invest in SPARC infrastructure. People will by Oracle Database Appliances. These will happen to have a few SPARC chips in them. When you buy an Oracle license, the hardware will be part of the bundle.

      --
      I am TheRaven on Soylent News
    81. Re:and? by TheRaven64 · · Score: 1

      When you say 'SPARC' what do you actually mean? The Tx series are known to be very weak in terms of FPU performance. The T1 had one FPU per die (shared between all cores). The T2/3 have one FPU per core, but it's shared between all contexts, while other ALUs are often duplicated. On the other hand, the SPARC64 systems from Fujitsu are much stronger, and are found in a few of the top 100 supercomputers.

      --
      I am TheRaven on Soylent News
    82. Re:and? by dogsbreath · · Score: 1

      That's quite a bizarre claim. I've looked at hundreds of Java dumps from hundreds of different customers and the vast majority are doing multithreading on a massive scale with no issues. If there is contention it's usually pretty obvious from the dump.

      I can only assume that your company's software is quite poorly designed from a threading perspective.

      Not bizarre, just what we see. For the most part, we don't write the apps that we have to serve up. Network h/w vendors provide management s/w and we have to implement it in a scalable, available structure and we have to meet performance and other typical requirements. Fact is, most of the software is crap.

      However, even when we have software from vendors who claim to have addressed threading in their application architecture, design and implementation, we find performance issues that preclude the use of the Sun T servers.

      Writing fully parallel apps that don't have blocking paths seems to be difficult. I have run DTrace sessions to find performance blocks for software vendors when they appear to be unable to find the issues themselves. These sessions usually reveal file handle and memory leaks as well. The joys of using someone else's library (jar) and assuming it will handle everything consistantly. And this is with "mature" applications.

      Often, a s/w vendor seems to have made attempts at full threading but they are married to an app server that screws things up.

      I am no longer shocked by vendors lack of expertise with testing in a production level environment. It's like the developers ride around in go-carts on a closed track and figure that freeways will be the same only a bit bigger.

      In the end, we have found very few places where the current crop of T servers are appropriate.

      BTW, I am a h/w o/s guy and not a s/w developer.

    83. Re:and? by WarwickRyan · · Score: 1

      Because some posters speak more than one language? and make occasional mind farts when writing in English?

      "en" is a pluralising suffix in Dutch, and might well be in other languages.

    84. Re:and? by recharged95 · · Score: 1

      Sure they've made no new friends in the F/OSS world.
      But to all those former Sun customers with Sun poorly running their business, Oracle (a big company with lots of support) became an instant friend. And to all those potential business partners for Sun, but choose not to buy Sun cause it was losing money hand over fist, Oracle is making them reconsider. And for those customers wanting a stack based solution and didn't like IBM, HP, SAP, or even RedHat (huh?), Oracle brings a lot to the table. And that's paying customers I say.

      I say they've made more new friends in the business environment than losing friends in the F/OSS environment.

    85. Re:and? by causality · · Score: 1

      No, it's not the case that only the people who find your preferred solution compelling are smart. Sorry.

      If you believe that the majority of people who purchase computers or anything remotely related to IT are technically inclined and fully understand the technology they are purchasing then I'd like to see proof of that. The business majors who dominate corporate management generally do not fit this description, nor does the average consumer who "just wants it to work".

      My own smarts and whether or not I would personally be included in that majority have absolutely nothing to do with it. Whether you like the reality of the situation and feel a need to make this into a personal matter also has nothing to do with it. Well it does have one thing to do with it, indirectly -- it strongly indicates you use such a weak tactic because you have no actual argument.

      --
      It is a miracle that curiosity survives formal education. - Einstein
  3. Re:blindly pushing marketable limits... by MightyMartian · · Score: 4, Insightful

    I wasn't aware the Alpha was that bad. I thought it was simply that the benefit of the processors wasn't great enough to convince companies to move from the much cheaper x86 platform. I saw a couple of Alpha desktops and they were pretty impressive.

    --
    The world's burning. Moped Jesus spotted on I50. Details at 11.
  4. halve? by Anonymous Coward · · Score: 0

    is another veiled sun downsize?

  5. Bill Gates was quoted... by Anonymous Coward · · Score: 0

    Bill Gates was quoted as saying "320 cores should be enough for anybody".

  6. Concentrate on ST perf? What does this mean? by multipartmixed · · Score: 3, Interesting

    Does it maybe mean more register windows?

    Because that would certainly help things like Java, and presumably oracle.

    Anybody know how often a large query spills registers?

    --

    Do daemons dream of electric sleep()?
    1. Re:Concentrate on ST perf? What does this mean? by Surt · · Score: 2

      I assume they're talking about improving their multiple dispatch, so that they can go from 3 - 4 (or is it 4-5) ops in parallel on a single core. And probably bring up the clock speed. 8 cores at 2ghz beats 16 cores at 1.5 ghz for a lot of applications.

      --
      "Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
    2. Re:Concentrate on ST perf? What does this mean? by Anonymous Coward · · Score: 0

      that would certainly help things like Java

      God yes. I can not believe how badly Java runs on SPARC. I mean, okay, logically it probably did make sense to concentrate on Windows performance first and general x86 performance second, but it just always seemed crazy that Sun's hardware was the absolute worst possible place to use Sun's programming language.

    3. Re:Concentrate on ST perf? What does this mean? by greg1104 · · Score: 1

      There are all sorts of common database paths where slow cores are troublesome. Acquiring locks, access to shared memory, writes to redo logs; these are all examples of things that can end up serializing more than is optimal if individual cores are slow. Because of this, half as many cores that run at twice the speed is not the same net speed; it's probably faster, because each process is introducing less contention. Reducing the time things hold onto shared resources is really important for database workloads, and the easiest way to do that is to make the cores so fast they get in and out of holding access to those resources as quickly as possible.

      This is not at all limited to Oracle either. I used to have a Sun Fire T2000 server using the 32-thread UltraSPARC T1 chip at my office. Running PostgreSQL, that system was trounced every time we compared it to x64 systems from Intel and AMD with much lower core counts but higher clocks. Sun released some specific compiler tuning magic for MySQL to make it perform better on that processor that helped. It sounds like after looking at the same trade-offs here, Oracle has decided to just go for the traditional solution--faster cores--rather than to try and optimize their software design for the processors. Can't say I blame them.

    4. Re:Concentrate on ST perf? What does this mean? by multipartmixed · · Score: 1

      Thanks for the note -- FWIW those tuning options should work well pretty much anywhere, as he's demonstrating how to turn on whole-application PGO.

      I guess I'm one of the lucky few with no DB workload issues; my DB server hums along at about a ~1.0 load average on a v240 during busy hour.

      Of course, my workload is 98% select, no stored procedures, no triggers, no joins, few transactions...

      --

      Do daemons dream of electric sleep()?
  7. Same as always by matfud · · Score: 1

    I'm pretty sure this was on Suns roadmap. Higher throughput per thread. Higher clock speeds. So have Oracle deviated from the plan Sun had?

    1. Re:Same as always by Anonymous Coward · · Score: 0

      Oracle actually has the money to do it.

  8. incoherent by Chaostrophy · · Score: 1

    I don't think the author had any understanding of the history of SPARC or Oracle (Sun)'s product linup. Here is an informative interview from the useful Sun hardware oriented blog on the subject http://www.c0t0d0s0.org/ http://www.oracle.com/us/corporate/innovation/innovator-hetherington-191304.html

    --
    Plato seems wrong to me today
  9. Sparc by TopSpin · · Score: 5, Informative

    The reduction in cores from 16 to 8 was part of the Sparc road-map before Sun was acquired by Oracle. Despite a lot of speculation it appears Oracle is following through with the plans they bought from Sun.

    ... Sun was going to cut back the number of cores to eight and crank the clocks to 2.5 GHz ...

    --
    Lurking at the bottom of the gravity well, getting old
  10. Re:blindly pushing marketable limits... by bhtooefr · · Score: 4, Informative

    ISTR benchmark after benchmark saying that they performed about as well as a Pentium Pro/II of the same clock speed, when running native code. Except they were doing 533 MHz when Pentium Pros were doing 200. Oh, and the benchmarks I remember showed that the Alpha could emulate x86 code as fast as the Pentium Pro 200 could run it natively, after DEC's emulation software had profiled the code.

    The problem is this... they were also, IIRC, more EXPENSIVE than said Pentium Pro machines, and they could (for the Windows market) only run NT, when everyone targeted 95. And the performance advantage was completely wasted if your code wasn't written for Alpha. (So, you could run Office 95 and such on them, but because Microsoft only compiled the OS and maybe some server software, for general desktop AND workstation duty if your business needed Windows, a PPro box was cheaper and may have been able to do the same job.)

    (Keep in mind that back then, Microsoft was ambivalent about x86, at least in the workstation and server market. Windows NT was written to run on quite a few popular processor families - MIPS, PPC, and Alpha, in addition to x86. And, Microsoft made what was essentially an AT Architecture MIPS system specification for running NT on MIPS.)

  11. Re:blindly pushing marketable limits... by jedidiah · · Score: 1

    um no...

    Alpha systems were well worth 4x their other contemporaries.

    They made things possible that were simply unable to scale on Solaris kit.

    This is why they were also thrown into some of the early computing clusters and render farms.

    OTOH: SGI are the poster boys for overpriced gear with lack luster performance.

    --
    A Pirate and a Puritan look the same on a balance sheet.
  12. Keep the Cores; Make Them Faster by Doc+Ruby · · Score: 2

    Reducing the core count lets Oracle make each core bigger, to add features making each faster. But can't Oracle keep the same core count, and instead of increasing the core count in the next generation the way most other CPU makers will, just add circuits to each existing core? Is it really necessary to reduce the count? Process size will probably also be shrinking in that generation, and new tricks developed, as usual. Can't Oracle just make a bigger chip, and also keep the benefits of the high core count Sun already achieved?

    --

    --
    make install -not war

    1. Re:Keep the Cores; Make Them Faster by GWBasic · · Score: 1

      Reducing the core count lets Oracle make each core bigger, to add features making each faster. But can't Oracle keep the same core count, and instead of increasing the core count in the next generation the way most other CPU makers will, just add circuits to each existing core? Is it really necessary to reduce the count? Process size will probably also be shrinking in that generation, and new tricks developed, as usual. Can't Oracle just make a bigger chip, and also keep the benefits of the high core count Sun already achieved?

      From what it sounds like, Oracle could be devoting the extra space to cache. A large cache can go a long way in CPU-bound operations; or help make a very fast database.

      Making a bigger chip isn't as easy as it sounds. As the die size increases, the probability of a defect within the die increases. (Imagine that you have 5 specs of dust on a wafer, if the die size is larger then the ratio of good to bad is worse.) Large die sizes will also have problems with heat distribution, or could limit total clock speed due to irregularities that small die sizes mitigate.

    2. Re:Keep the Cores; Make Them Faster by Surt · · Score: 1

      An increasing number of cores tends to be a challenge to keep clocked at a high speed. Every CPU developer struggles with this, and they all market higher clocked lower core count parts. Choosing to go for a lower core count in your design phase makes a lot of sense if you are single thread bound.

      --
      "Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
    3. Re:Keep the Cores; Make Them Faster by dgatwood · · Score: 1

      This is why you build each group of cores and the corresponding cache on a separate die, test and bin each die independently, then wire them together inside the package. Sure, there's the added potential for interconnect failure, but so long as you test the integrated module before you epoxy the lid on, you should be able to salvage those parts.

      --

      Check out my sci-fi/humor trilogy at PatriotsBooks.

    4. Re:Keep the Cores; Make Them Faster by mlts · · Score: 1

      Oracle could have always gone the route IBM did with the POWER7 chips and have the best of both worlds. With Power7, you can turn half the cores off. The remaining cores will use the cache on the counterparts that are off, and the clock speed gets a decent bump.

      This is what Oracle should have done -- if someone is doing a task that is easily split up into parallel parts, or using a lot of domains/VMs, allow for this. If they need more oomph per core, have half the cores flip off, and the others use their cache.

    5. Re:Keep the Cores; Make Them Faster by drinkypoo · · Score: 1

      Holy increased cost batman! Interconnects aren't cheap.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    6. Re:Keep the Cores; Make Them Faster by GWBasic · · Score: 1

      This is why you build each group of cores and the corresponding cache on a separate die, test and bin each die independently, then wire them together inside the package. Sure, there's the added potential for interconnect failure, but so long as you test the integrated module before you epoxy the lid on, you should be able to salvage those parts.

      Sounds expensive

  13. Re:blindly pushing marketable limits... by Anonymous Coward · · Score: 0

    useless on the desktop

    I had Alpha's on the desktop in '97. They were excellent and you are the very first I've ever heard characterize those machines as 'useless.' That's just silly. People still trade those things on E-bay and they get good prices. I watched tens of millions of dollars of revenue engineered on those machines.

  14. Re:blindly pushing marketable limits... by matfud · · Score: 3, Informative

    It really depended on what you wanted to do. Sparc machines where great at IO and memory access. Alphas just had the shear grunt to do work (and yes they were running at over 1GHz when most processors where running at half that)
    . SGI were crap but if you wanted to visualise it they could not be beat (hudge amounts of custom graphics hardware).

  15. Re:blindly pushing marketable limits... by MichaelKristopeit212 · · Score: 0
    i watched 10 times as much engineered on sun and SGI machines... my COMPAQ PRESARIO outperformed my alpha on some tasks running at less than half the clock speed.

    they were RELATIVELY useless.

    i'm a fan of the MIPS architecture and loath things like hyper-threading, but throughput doesn't lie. there was obviously a lot of bad programming on the OS layer as doing anything in the file browser would cause the window to reload every single element and redraw it... super lag... hard to blame the chip for stuff like that, but there simply wasn't enough software optimized for the architecture.

  16. I'll see your 16 cores and raise you 1024... by metalmaster · · Score: 1

    but that doesnt really matter now does it? We know your application only supports 2 and scalability isn't an option.

  17. Re:blindly pushing marketable limits... by MichaelKristopeit212 · · Score: 0
    yeah, that's what we were doing... lots of imaging on gigantic data sets where latency was crucial (off site medical diagnosis). the SGIs outperformed everything

    the SGIs also outperformed the alphas for server daemons and we switched the math and computer science department web servers off the alpha.

    that is when i first realized the Mhtz race was useless marketeering... what good is horsepower without proper gearing? the alphas seemed to lag behind everything else i had access to despite having almost triple the clock speed.

  18. Re:blindly pushing marketable limits... by Moridineas · · Score: 1

    my first hand experience as funded by the national science foundation says otherwise.

    Well let's see some numbers then. My firsthand experience (admittedly not funded by NSF!!!) says you're dead wrong. Secondly, who exactly claimed that Alphas were cheap? They WERE more expensive, but also more powerful.

    do you have any insight of your own to provide? why are we all not using alpha chips if they were so affordable and powerful?

    Perhaps you've heard the term "Wintel" before?

  19. Re:blindly pushing marketable limits... by MightyMartian · · Score: 1

    That's rather my point. The Alpha was anything but a bad chip, it's just that on a cost-benefit scale for what they were being marketed for, it made no sense. The problem, at the server and high-end workstation end, was that while the Alpha could certainly outperform Pentiums, the price made them very unattractive compared to the Intel was throwing out there.

    --
    The world's burning. Moped Jesus spotted on I50. Details at 11.
  20. Re:blindly pushing marketable limits... by KonoWatakushi · · Score: 1

    The DEC Alpha was (and still is) a brilliant architecture. The designers took great care from the start to make sure that it would scale, both in clock and core count. It was simple, elegant and fast.

    IIRC, the early chips were fast enough to emulate x86 code at a reasonable speed. If all you wanted to do was run emulated x86 code though, then maybe they were "useless". This was especially true before the BWX extension, which introduced a number of byte oriented instructions.

    Native code, on the other hand, would leave you with no misconceptions about the speed of the Alpha; it was truly impressive. DECs compilers and math libraries were also excellent.

  21. Re:blindly pushing marketable limits... by Johnno74 · · Score: 1

    IIRC the original athlon actually licensed some of the features of the alpha from DEC too...

  22. Sanity, at last! by kanto · · Score: 3, Insightful

    When will people realize that not everything runs better on more cores, especially stuff that's highly dynamic say like a database query which is effectively a long sequence of conditionals. You talk to people and the first thing they ask is "yeah, but how many cores does it have"... it's like multithreading didn't exist until dualcore cpus.

    A cpu has a limited amount of processing power; some things you can only do in sequence ergo you can't do them in parallel ergo you're limited by the core-speed ergo you're fucked with 16 core 1GHz machine against a 1 core 2GHz machine.

    1. Re:Sanity, at last! by Surt · · Score: 1

      Not everything runs better on more cores, but so many things scale close to linearly with cores that it has become what the majority rightly want. Basically every business function that has to support N users can be partitioned over up to N cores, the more cores you pack per chip, the less chips and sockets and boxes you have to buy.

      --
      "Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
    2. Re:Sanity, at last! by kanto · · Score: 1

      Yup, it's a balancing act and I'm not saying that you should never do multicores, just that it doesn't do to forget the actual performance of the system on the tasks that it's supposed to be running. N users on N cores sounds very good if none of those users need to go beyond the max speed of the cpu or their task multithreads beautifully. Sometimes though, you could with 1/N memory (assuming memory speed won't be a bottleneck) and an N-times faster cpu serve those N-users and only one would have to wait for the same time it would take on an N core machine... it all depends on what you're doing.

  23. Re:blindly pushing marketable limits... by matfud · · Score: 1

    I have had various experiences. For some of my work the Alphas trounced everything. They were very fast processors. Larger data sets and I found that sunOS on fujisu (sparc) machines worked beter. Mind you I may be biased as the 16 proc machines I had access to were not quie comparable to the alphas (I think the alphas still out performed in floating point though).
    But If you wanted to see your data then you had to have something from SGI. SGI really had impressive 3D hardware. Most low end 3D grphics cards can propbably out do SGI now but having to have 8 or 16 full length cards at a few grand a piece was fun. That was the first time I used 3D graphics.

  24. Re:blindly pushing marketable limits... by ducomputergeek · · Score: 1

    It really depended on what you were doing too. Alpha's were built for raw speed and were good for certain tasks. Company I worked for back then used them for Lightwave rendering circa 1996/1997. But I believe the average box was somewhere in the neighborhood of $35,000 - $50,000 a pop for Dual 500 Mhz, 2GB of RAM and pretty much were all render nodes. Most of the workstations were SGI/IRIX and in the early days there were even quite a few Amiga around.

    --
    "The problem with socialism is eventually you run out of other people's money" - Thatcher.
  25. crypto by Anonymous Coward · · Score: 4, Informative

    At the very least, Oracle has introduced a great deal of uncertainty into Sun products, so you have to ask "What does Sun hardware offer than other hardware doesn't?". With all the bad press, they have an uphill battle converting people to Sun from other platforms, and for those who have a choice, what *exactly* is the big benefit that can't be purchased from someone else for less?

    Do you care about crypto at all? If so, the T-series CPUs have on-die MD5, SHA-1, SHA-2 family, DES, 3DES, AES (multiple modes of operation), RC4, RSA (up to 2Kb), and ECC acceleration, as well as RNG. The T3s can do almost 80 Kop/sec for RSA 1024. All you have to do is link against the Solaris-provided OpenSSL library and call the appropriate "engine" APIs to activate things (this is built-in to a lot of FLOSS software already (e.g., Apache)).

    The T5220 (T2 processor, the T3 just came out) has been benchmarked as doing 44 Gb/s AES128: and that's on the crypto co-processors, so the "real" processors are free to do "actual" work--like serving HTTP requests. At the same time as this, the T2 can also do 38 Kop/sec of RSA 1024. At the time this benchmark was published, a quad-core Xeon 3 GHz could do about 8 Gb/s AES1028 and 9 Kop/s of RSA1024 signing--with little to nothing left over to do anything else.

    So you ask, "what can these systems do?" Well, how about: instead of paying for a bunch layer of load balancers to do SSL and RSA, and a whole bunch more machines to do actual web requests, why not just buy a lot fewer T2s (now T3s), and save power, cooling, and rack space?

    The T-series is not good at everything, but for the mutl-threaded, multi-client workloads it was designed for it works very well.

    1. Re:crypto by segedunum · · Score: 1

      Do you care about crypto at all? If so, the T-series CPUs have on-die MD5, SHA-1, SHA-2 family, DES, 3DES, AES (multiple modes of operation), RC4, RSA (up to 2Kb), and ECC acceleration, as well as RNG. The T3s can do almost 80 Kop/sec for RSA 1024. All you have to do is link against the Solaris-provided OpenSSL library....

      No one cares, seriously. encryption acceleration/decryption is not going to save Sun's hardware business nor stop it from losing money. For those that need them they have had hardware accelerated encryption and decryption for some time.

    2. Re:crypto by TheSunborn · · Score: 1

      What usage is the ability to encrypt 44Gb/s when the webservice running on the computer can't generate data at that rate. (And you can't send that much data either, because you don't have network hardware on the server to do it).

      Must servers only output a few Gb/s at most, and at that rate the extra cpu usage is so low that it will be difficult to measure (When using ssl).

      But let us say that you need something which do output 10Gb/s. What you do is you buy a dual Opteron motherboard. Put in 2 12 core processors.
      Then you will at most need 1 core per processor to do the encryption, and you will still have 2*11 cores left to do generation of pages.

    3. Re:crypto by TheRaven64 · · Score: 1

      Correct me if I'm wrong, but don't the top of the line Tx systems come with dual 10GigE, meaning that the ability to do crypto at anything more than 20Gb/s (less, when you factor in protocol overhead) is wasted? I suppose that you might be running SSL over IPSEC and need double that, but it seems like you're very unlikely to need anything like this performance.

      --
      I am TheRaven on Soylent News
  26. Re:blindly pushing marketable limits... by MichaelKristopeit212 · · Score: 0

    the available native code was relatively non-existent.

  27. Re:blindly pushing marketable limits... by luis_a_espinal · · Score: 1

    alphas weren't much more expensive... if i remember right $800 got a 1.2 Ghtz bare bones system... about the same as a 433Mhtz with pentiums.

    got it... so the ignorant public just never UNDERSTOOD how good the alpha product was and that is the reason they didn't buy it.

    you're an idiot.

    if only microsoft had dedicated itself to a symbiotic relationship with alpha to cross optimize... wahhhhh wahhhhh.

    perhaps one day you'll not be an idiot?

    Apparently, gratuitous insulting has become the cornerstone of logical arguments. Bravo.

  28. Re:blindly pushing marketable limits... by mr_mischief · · Score: 1

    Because Intel sued them over patents and buried the tech?

  29. Re:blindly pushing marketable limits... by Anonymous Coward · · Score: 0

    In case you haven't noticed MichealKristopeit* is a notorious sockpupeting troll. The amazing thing here is that he's somewhat on topic for so long.

  30. Re:blindly pushing marketable limits... by Anonymous Coward · · Score: 2, Insightful

    Yeah I had a 486-DX100 and a 233 MHz Alpha 21064, both running Red Hat Linux.

    The Alpha was so much faster for native compiled stuff, but I couldn't get Netscape for Alpha, and running Netscape for x86 under the EM86! emulator was as slow as browsing the web with a Python based browser at the time. They were both too slow to keep up with "fast" downloads like a 28k modem... So I wound up using the 486 machine as my graphics console, and running all of my batch stuff on the Alpha, with them sitting next to each other connected by cheap coax ethernet.

    What amazes me is that I now have a quad core 2.4GHz Intel i7 Xeon with 12 GB of triple-channel RAM and gigabit connection to the internet here at work in a university, and I still get uncomfortable lags with browsing. Compared to my 486DX-100 and 20 MB of RAM, I am not sure I see that much more value in todays web to warrant this level of resource overhead. I expected us to be in the sci-fi future by the time we had this kind of equipment...

  31. Re:blindly pushing marketable limits... by matfud · · Score: 1

    "That was the first time I used 3D graphics."
    Perhaps I should say this was the first time I had used 3D graphics in anger. No textures...just trying to push polygons at the screen. trying to render voxels using GLUT/GL. That is when I started to apprecieate the SGI machine I had access to. It was too slow to compute the scene but nothing else could display it fast enough to get an idea what was going on.

  32. Re:blindly pushing marketable limits... by KonoWatakushi · · Score: 1

    That is what compilers are for. It is silly to suggest that there was no software for a Unix based system, especially at that time.

    Availability of Windows based software would have helped, but was hardly necessary. The market didn't kill the Alpha, it was pure stupidity on the part of management.

  33. Re:blindly pushing marketable limits... by matfud · · Score: 1

    Oh and this was using the shuttered glasses (LCD) that give you a headacke after ten mins. They claimed 30 hz but that did not really work. The pressure ball controll did work well.

  34. Re:blindly pushing marketable limits... by Moridineas · · Score: 1

    alphas weren't much more expensive... if i remember right $800 got a 1.2 Ghtz bare bones system... about the same as a 433Mhtz with pentiums.
    got it... so the ignorant public just never UNDERSTOOD how good the alpha product was and that is the reason they didn't buy it.

    So what you're saying is that no, you don't have any performance numbers that can remotely back up anything you've claimed?

    you're an idiot.

    if only microsoft had dedicated itself to a symbiotic relationship with alpha to cross optimize... wahhhhh wahhhhh.

    perhaps one day you'll not be an idiot?

    Classy.

    "Wintel" won as a platform because it was common, cheap, fast (enough) and yes, because Microsoft was very important to the PC landscape! Look at other chips like PowerPCs and so on that had some great performance and energy qualities but were dominated by Intel chips and Microsoft OS/software.

    Is it true that you're a notorious sockpuppeting troll? I don't think I've seen your name before.

  35. Re:blindly pushing marketable limits... by Moridineas · · Score: 1

    no, actually the norm is tongue in retarded cheek backhanded rhetorical implications like "Perhaps you've heard the term "Wintel" before?".

    Yes, one can easily get into a pissing match over rhetorical techniques, like your "Funded by the NSF!!!" call to authority. Big whoop. My point was perfectly valid, and your inability to respond to anything I said lends credence to the AC who claimed you were a sockpuppeter.

    slashdot = stagnated

    Says the guy with the high 7-digit UID?

  36. Re:blindly pushing marketable limits... by Rudeboy777 · · Score: 1

    If you think the web is a bloated mess now, just wait until you see the hardware the sci-fi-future web will bring to it's knees!

    --

    From hell's heart I fstab at /dev/hdc

  37. Re:blindly pushing marketable limits... by afidel · · Score: 1

    The Athlon used the EV6 bus from the Alpha, in fact the AMD 751 and 761 northbridge chipsets designed for the Athlon were used by Samsung for Alpha 21264 based systems!

    --
    There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
  38. Re:blindly pushing marketable limits... by MichaelKristopeit213 · · Score: 0
    wintel won because of a symbiotic practice of cross optimization while patenting the use of provided optimizations on either end.

    you're an idiot.

  39. Re:blindly pushing marketable limits... by MichaelKristopeit213 · · Score: 0
    you think it's a big whoop that i've been paid for research?

    i've used all the systems first hand... the alphas ran the worst... obviously because of non-optimized software on every layer of the application stack. your inability to understand that the "AC" may very well be yourself as NO ONE has taken responsibility for the claims is hypocritically ignorant.

    this account is NEW. you're the same old idiot.

    bringing up such trivially irrelevant topics is again hypocritically ignorant.

    would you rather i post with my 5 digit UUACCOUNTUSERID? you're an idiot.

    if ANY user account CAN be a "sockpuppet" then ALL user accounts are "sockpuppets".

    cower some more, feeb.

    you're completely pathetic.

  40. Re:blindly pushing marketable limits... by hedwards · · Score: 1

    Depends upon the particular model. The DEC Multia was particularly problematic as it tended to suffer rather quickly from heat related problems and god help you if you were foolish enough to let it sit there flat while in operation.

  41. Re:blindly pushing marketable limits... by Moridineas · · Score: 1

    would you rather i post with my 5 digit UUACCOUNTUSERID?

    Yes, I would like that, please.

  42. Re:blindly pushing marketable limits... by RightSaidFred99 · · Score: 1

    Revisionist history much? DEC sued Intel. This was...unwise, and Intel sued them back. The companies did, however, settle.

  43. Not what I meant Oracle! by SuperKendall · · Score: 1

    I said "Can HAVE cores plz"!!!!

    --
    "There is more worth loving than we have strength to love." - Brian Jay Stanley
  44. Re:blindly pushing marketable limits... by TheLink · · Score: 2

    What amazes me is that I now have a quad core 2.4GHz Intel i7 Xeon with 12 GB of triple-channel RAM and gigabit connection to the internet here at work in a university, and I still get uncomfortable lags with browsing.

    I expected us to be in the sci-fi future by the time we had this kind of equipment...

    One reason why so many things are still slow is because a lot of timeouts and delays are set to human-scale: on the order of seconds. Not milliseconds or microseconds.

    The next reason is the speed of light isn't that fast.

    And the last reason is what Intel giveth the Programmers taketh away. I'm guilty of this since I used to do 6502 machine code, but now write stuff in Perl (which on a modern machine can still do loops faster than a 1MHz 6502, but you can see where some of the speed gains have gone - I'm not sure how much work it would take for me to do a regexp match on a 6502 but I'm not going to even bother ;) ).

    --
  45. Re:blindly pushing marketable limits... by Moridineas · · Score: 1

    I was really hoping you would post with your 5-digit number :-(

  46. Re:blindly pushing marketable limits... by MichaelKristopeit160 · · Score: 0
    because you're an ignorant hypocrite.

    did your mother name you "Moridineas".

    you're completely pathetic.

  47. Re:blindly pushing marketable limits... by pantherace · · Score: 2

    Speaking as someone with an Alpha Station conveniently as a footrest...

    I'm calling a double bullshit.
    First of all the parent: 1.2GHz for 800 when Pentiums were 433MHz?
    21164 Alphas, topped out at mostly 600MHz, and were faster than x86 clock for clock. They were also pushing the MHz limit at the time, being the first to 500MHz, and using a slightly later 533MHz (21164PC) they were damned fast compared to any x86 chip. As far as speed, at the time, they were overall the undisputed fastest processors. (DEC only made up to 8 processor machines as I recall. At least I think that's the limit for the 8400, a quick googling shows a reference to 12 processors, so it's likely higher)

    21264 Alphas, were mostly released at under 800MHz, while air-cooled chips were demonstrated up to 1GHz, they weren't available. They were a lot faster per clock. (Of note, the Athlon used the EV6 (21264) bus which was one of the big reasons it did well. Plus a lot of DEC engineers going to AMD following the DEC/Compaq merger, which was if I recall correctly just before the 21264 was released, I don't recall any actual DEC hardware) Near the end P4s were released so you may be thinking 466MHz Alphas vs 1.2GHz P4s. (Where the Alphas would lose on integer, they would beat the P4s on floating point instructions) Benchmarking them, they were about 1.5x as fast clock for clock as at the time the fastest x86 processor (The original Athlon, mind you this is comparing optimized builds and the alpha didn't have SIMD instructions) If you were thinking of the API builds, you might be right, if you switch the MHz numbers around.

    21364 Alphas were released following the HP merger and were the only ones which were over 1GHz. At this time, it was way late. The FPU was still respectable, but overall it was a case of too little too late. The 364 was not even a new core, it was a 264 wrapped in a much better communication to the outside world, on-board memory controller, and a very hypertransport like connection. (Which predated Hypertransport, at least in the beginning of the design, but was delayed so much, that as I recall Hammer wasn't that far off)

    21464 was canceled, though it had a number of things, including the first Alpha SIMD instructions.

    The alpha, even the 21064s, which were petering out in favor of 21164s when I got introduced to Alpha, were not cheap. However, they (21164PCs anyway) were priced comparably to a high end x86 system. When x86 got better and cheaper, they simply didn't keep up. Part of that was due to a DEC-Intel suit/resolution, which as far as I'm aware Intel didn't hold up. Which eventually got DEC merged with Compaq. Then it was all the 'Itanium is the future', where Compaq ended up basically killing Alpha for. When HP got it, they were also heavily in the Itanium camp. HP also had their own prior processor (PARISC) which was being killed off for Itanium. Which as I'm sure you are aware the Itanic future didn't turn out the be the case.

    Second:
    Slow, was the one thing the Alpha was not. Expensive, rare, hot and some other things, but slow it was not. Considering that an Alpha led the SPEC cpu benchmarks for over 9 *continuous* years, being broken of the integer by P4 on release, and fpu by a much later P4 (See above for how the Alpha's frequency wasn't keeping up on the 264s)

    At no time, when alpha was being sold by DEC or Compaq, would SGI (MIPS) and Sun (SPARC) hardware have been faster per processor than Alpha. Look on the SpecCPU pages, or if you can find them (I can't) the old Seti@home statistics. Hell, look at just about *any* benchmark from around that time.

  48. Re:blindly pushing marketable limits... by cbope · · Score: 1

    The DEC Alpha EV6 bus was licensed for the original Athlon (and continued with the Athlon XP). EV6 in the original Athlon form was a 100MHz double-pumped bus (200MHz effective) and very good in its day, far better than Intel's 100-133MHz bus at the time. In fact it was a major contributor to the Athlon's long-term dominance over comparable Pentium's for some time. In the end, it reached 200MHz double-pumped (400MHz effective) speeds. Intel didn't match that until Netburst, and we all know how well that turned out...

    I don't recall any CPU-specific features were licensed from DEC... but I could be wrong.

  49. Re:blindly pushing marketable limits... by Moridineas · · Score: 1

    did your mother name you "Moridineas".

    Interesting question, but no, she didn't. It's actually kind of an amalgamation of a couple different things.

  50. OS/2 by orange47 · · Score: 1

    ah perhaps then we should use OS/2 instead of Solaris when they half single core CPUs..

  51. Re:blindly pushing marketable limits... by MichaelKristopeit160 · · Score: 0
    you cower behind a chosen pseudonym. what are you afraid of?

    you're completely pathetic.

  52. Re:blindly pushing marketable limits... by Moridineas · · Score: 1

    you cower behind a chosen pseudonym. what are you afraid of?

    Oh, could be any number of things...better safe than sorry! On the other hands, pseudonyms have a long and respectable history! You wouldn't criticize Publius, would you?

  53. Re:blindly pushing marketable limits... by MichaelKristopeit160 · · Score: 0
    ur mum's face wouldn't criticize Publius.

    you're an idiot.

  54. Re:blindly pushing marketable limits... by Jeppe+Salvesen · · Score: 1

    Hey, hey, hey, don't assign stagnated to slashdot! You mean slashdot == stagnated. (Unless you're writing Ada, then you're right)

    --

    Stop the brainwash

  55. Re:blindly pushing marketable limits... by MichaelKristopeit160 · · Score: 0
    i'm right for more reasons than you'll ever know.

    you're an idiot.

  56. Re:blindly pushing marketable limits... by Anne+Honime · · Score: 1

    I see we have the same footrest / foot warmer. Mine's a lousy PWS 433, but it used to run loops around any PPro in its days. Still keep it for that little Quake game now and then... incredibly smooth gameplay...

  57. Sun Already Tried This by turgid · · Score: 1

    Sun already tried this and had to give up. Sun's CPU design team just couldn't get the mode complex cored to work at competitive speeds.

    I think that Oracle is making a big mistake here. They should let Fujitsu develop the big cores (which they are supremely good at) and themselves concentrate on the highly-multithreaded ones, which they are good at.

    I don't see why this is a problem for developers, since the compilers take care of the CPU-specific details, and if your code is written in Java, it's a non-issue anyway.

  58. Re:blindly pushing marketable limits... by drinkypoo · · Score: 1

    Alphas ran VMS, NT, or Digital UNIX (nee OSF/1) none of which were designed ground-up for the user experience. But I had an Alphastation 3000/300X and it was tolerably peppy, so I think you're just imagining things.

    --
    "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
  59. Re:blindly pushing marketable limits... by drinkypoo · · Score: 1

    The alpha was never intended to run NT really, but Microsoft was reaching out in all directions trying to see what would fly. Remember Microsoft Talisman? Neither does anybody else, but the hardware was essentially done when they canned it because they had totally misjudged the market. It was intended to be available as a big package which also included ISDN which was left in the dust by DSL and cable modems.

    --
    "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
  60. Re:blindly pushing marketable limits... by Anonymous Coward · · Score: 0

    i remember in 1997 alpha processors ran over 1Ghtz when no other processors did, but they were useless on the desktop.

    the problem is obviously attention to detail... engineers who do not take pride in the functional optimization of their products.

    Drugs were better back then. 1997 Alpha processers were at about 4-500MHz. The 1GHz Alphas didn't come into 2002 or so.

  61. Too Little, Too Late - At Least For Us by Petersko · · Score: 1

    My job is to maintain and enhance an industrial scheduling system. The G2-based platform is single threaded, as is the simulation engine (written in C++). It's grown from 3 concurrent users in 1999 to 31 today, and from 50 simulations per day to nearly 300. We've moved from SPARC to SPARC when new chips offered better prformance. The engine was written for, and so far can only be compiled with, Sun's compiler.

    I'm sure we're not alone in having significant investment in single-threaded computational software. We've decided to ditch Sun, and a project is currently under way to port the engine.

    It's a shame. I really quite like the stability we get on SPARC. But they've been too stagnant, and we've grown tired of waiting. Throw in the risk of losing support for hardware running a critical system, and there's no way we can stay on Sun.

  62. Re:blindly pushing marketable limits... by Moridineas · · Score: 1

    Ah well, I was hoping you would get down-modded some more to save people in the future having to read your comments. Maybe next time! Cheers

  63. Re:blindly pushing marketable limits... by mr_mischief · · Score: 1

    Who started the suit doesn't much matter. Intel sued and won. That's why the Alpha is no longer its own line of chips. Any technology from the Alpha that Intel got in the settlement went into their chips. Any DEC got to keep went to Compaq then HP, and likely ended up in Itanium through them.

  64. Re:blindly pushing marketable limits... by MichaelKristopeit160 · · Score: 0

    ur mum's face're imagining things

  65. Re:blindly pushing marketable limits... by MichaelKristopeit139 · · Score: 0
    you thought you could silence me?

    you do not believe individuals have the right to speak and be heard?

    why do you cower behind a chosen pseudonym? what are you afraid of?

    you're completely pathetic.

  66. Re:blindly pushing marketable limits... by Anonymous Coward · · Score: 0

    wow, forgot your meds again huh?

  67. Re:blindly pushing marketable limits... by MichaelKristopeit139 · · Score: 0
    does every ignorant coward unwilling to take responsibility for their statements believe that every person able to point out their ignorance requires "meds"?

    forgot your education? never received one? unable to learn, huh?

    why do you cower? what are you afraid of?

    you're completely pathetic.

  68. Re:blindly pushing marketable limits... by Moridineas · · Score: 1

    Well, I didn't think I personally could silence you--you've shown more than enough willingness to keep talking! I did think that others might moderate you down (and I guess they did).

    Publius!

    Cheers

  69. Re:blindly pushing marketable limits... by Frosty+Piss · · Score: 1

    You show signs of serious mental illness, "Michael Kristopeit". You say you're a gun collector? Perhaps your neighbors should know...

    --
    If you want news from today, you have to come back tomorrow.
  70. Re:blindly pushing marketable limits... by Moridineas · · Score: 1

    Since you're new to slashdot, here's the moderation FAQ, FYI: http://slashdot.org/faq/com-mod.shtml

  71. Re:blindly pushing marketable limits... by MichaelKristopeit215 · · Score: 0
    don't need ignorant ramblings from broken system architects to LOOK UP AND COUNT 0 COMMENTS MODDED DOWN.

    you're an idiot.

  72. Re:blindly pushing marketable limits... by Moridineas · · Score: 1

    Oh ok, sorry I couldn't help!

  73. Re:blindly pushing marketable limits... by yuhong · · Score: 1

    Except they were doing 533 MHz when Pentium Pros were doing 200.

    Yep, when the so-called megahertz myth was true. P4 was Intel's attempt to abuse it.