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."
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.
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.
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()?
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.
Lurking at the bottom of the gravity well, getting old
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!
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
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.)
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
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).
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.
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.
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.
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.
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.
"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.
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...
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.
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
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
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!
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.
relax dude, why are all your posten so serious
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.
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 ;) ).
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.
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.
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.
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