Oracle is abandoning AMD's Opteron processors, according to a person familiar with the company's server plans. The new owner of Sun Microsystems will not use the new Opteron 6100 and impending Opteron 4100 processors in future Sun Fire x64 servers, and all existing Opteron servers will be discontinued. Thus ends an Opteron era …
The end of an era
Intel opened a window of opportunity through the disastrous move of its development into a place more interested in expenses fraud and saying yes to whatever marketing dumps across 12 timezones after some bolivian marching powder and whalesong.
This window of opportunity has now shut. At the time AMD made the best use of that decision and the fact that intel crippled most of its development . However, Intel has moved it to places which know how to spell NO and how to deliver. As a result it has caught up and surpassed AMD.
There is a lesson there somewhere which a lot of other companies like Yahoo and nearly all telecoms "giants" have yet to learn. You do not move your development into a country that does not know how to say NO and which has an upper salary limit.
You can of course do 8-way opterons too, on the previous gen CPUs, in fact both of HP's 8-way systems are opteron only
In fact at least in vmware testing an 8-way 6-core opteron(48 cores total) was faster than a 16-way 4-core Intel box (64 cores total - NEC system I believe). I can imagine the 8-way system cost quite a bit less too.
Of course an 8-way 6-core opteron is about the same performance as a 4-way 12-core opteron. So I certainly agree with AMD's move to ditch servers with more then 4 CPUs. Really good strategy.
They have two options - Intel or AMD in the x86 space and it is reasonable not to spend money on duplicate designs. Customers don't really care about Intel vs AMD - they care about system performance, reliability, scalability and correctness.
The question Intel vs AMD is acutally a detail that customers don't need to care about as long as they get good system performance and a competitive price (and the above things).
Oracle does not talk about irrelevant things and that is good. They definitely need a full-blown x86 strategy to succeed and they will choose the CPU that will allow them to do that in the best possible way, I assume.
If they still mess around with SPARC, then I feel very sorry for Oracle shareholders.
Some DO care if its AMD or Intel
Intel has plants and significant investment in Israel, who's lone ally is the US. Customers in neighboring countries prefer not to buy products made in a country that has a poor human rights record, starves residents of Gaza, and maintains apartheid policies towards Palestinians. I learned this important lesson when trying to sell our products to Saudi's. They only had interest in our Sun Sparc-based products. So, yeah, an alternative to Intel is very important to some customers.
errr... RE: jlocke x86
RE: jlocke x86 .... "If they still mess around with SPARC, then I feel very sorry for Oracle shareholders."
If you knew *anything* about SPARC in the last decade you would not make this comment.
SPARC processors of late have become a monster that under some circumstances leave the x86 world wondering if SPARC cheated in the exam! The fact that SPARC run significantly slower I gather is your measure of comparison. And whilst Ghz and such are important for many tasks, for some the ability to use up and down cycles of the bus are more important (along with the cores and threading and RAM being dedicated to a thread) - this is where the SPARC for hundreds or thousands of small / quick tasks can finish and be enjoying lunch whilst the much faster but slower throughput x86 chip is still busy pushing through its lower number of cores. A large number of threads can be important to those that dont write single-threaded apps.
SPARC has a good future for some tasks, and the x86 design wont ever be able to compete in those areas ... until they get to 64 core per CPU and then the RAM is still the bottleneck.
SPARC and x86 are very much like apples and oranges, they might be both a fruit but they are not the same.
Is that something imposed by law ? Oracle defintely is doing a worse job than Sun did about communication. Nobody can get anything out of it and Oracle doesn't seem to care.
It's no secret that Larry is best buds with Lord Jobs, the master of keeping schtum about future products. Perhaps Larry thinks he can be just like his mate and generate an air of mystery about himself and company. Larry's mouth is too big for that to last long!
Dog turd or hamster turd ... still a turd.
Anything x86 is a turd. Oracle has Sparc, they should be dumping *all* x86/64 roadmaps and offer a smooth transition to Sparc64 instead. They already have all their users under Solaris or Linux, jumping to another arch isn't that hard. Oracle is one of the few companies that could actually make people switch to something good; AMD was the only innovator, and the only thing they really did was bolt on 64-bits on the crappy Intel arch.
I may not like x86
but I'd also not like to see such a counter-productive move. haveing an x86 offering helps the bottem line as people buy it. SPARC is a harder sell. One is better for some computing applications, one is better for the bussness. dropping the 2nd would be foolish at best.
"jumping to another arch isn't that hard"
"jumping to another arch isn't that hard."
Any responsible program manager, marketing person, or techie should realize that "jumping to another arch" puts _EVERYTHING_ back on the table. If your customers are considering that kind of move (perhaps because your company forced them into it), they would be irresponsible to disregard other options. If they are forced to rebuild and re-qualify whatever it is they are doing, they will look at other vendors, other technologies, everything. Suddenly the pain of switching over to a completely new direction (hence - away from the current vendor) becomes tolerable.
Most companies would rather chew on tin-foil  than force their customers through such a transition, because they _will_ lose some percentage of their (formerly) loyal customer base.
 Two dissimilar metals in a wet environment conduct a current.
turd vs turd.
Ohhhhh so you mean Oracle should move customers from a chip set that they don't own to one that they do! Hey wait a minute, is that laughter coming from a board room somewhere in Japan?
CPU development is fairly pricey these days
Making a competitive CPU isn't easy - you need access to modern fabs, a skilled R&D team and a lot of money. Sun was lagging behind because it couldn't make a CPU fast enough to be competitive with X86/X64 and Power. Much of Sun's kit is actually based on CPUs made by Fujitsu, and pundits were picking Fujitsu to buy them out for years.
HP (wisely or otherwise) canned both PA-RISC and Alpha because the R&D costs were too high and Intel conned them into thinking Itanium had a future. Itanium is not particularly fast by modern standards and is more or less on life support through server chipset components shared with X64 systems.
MIPS lost its competitiveness in the early 2000s as they just couldn't keep up in speed with commodity CPUs. The last SGI workstations had CPUs clocked at around 700-800MHz in the mid 2000s when a P4 (even though it wasn't as fast clock for clock) ran at 3-4x the clock speed. SGI stopped making workstations around 2006. Drinking the Itanium Kool Aid was the final nail in the coffin and they're now owned by Rackable systems, who took over the branding.
IBM has enough volume to keep Power going through merging the hardware platforms behind the p and i series. They have good fab facilities, so they can make Power fast, so Power is the only modern CPU architecture that can keep up with Intel. IBM is the last man standing against Intel, mainly on the strength of their incumbency in big iron.
Oracle is in the database business and bought Sun so it could sell integrated database appliances and position itself as a one-stop I.T. services vendor. They don't care about CPU architecture - Oracle 11g runs on something like 10 different platforms and 10g runs on more than 20. Historically they've supported dozens.
Oracle is very portable and most SPARC/Unix software will port to Linux (or even AIX) relatively easily. Sun don't have IBM's base of legacy software tied to a proprietary platform. Unless Fujitsu pulls a rabbit out of the hat with their SPARC offerings we're likely to see the SPARC/Solaris platform slide into obsolescence. If Oracle made a Xeon-based system fast enough and thought they could get their customers to migrate they might even drop SPARC altogether.
If Oracle bends over does the Sun still shine?
turd vs turd
Ohhhh so you mean Oracle should move customers from a chipset they don't own to one that they do!..... Hey wait, is that the sound of laughter coming from a board room in Japan?
Most of us agree x86 is a piece of shit, buggy and bloated. But it is a fast piece of shit. And cheap. And development pace is extremely fast.
The new 32nm version of Nehalem-EX next year, should be even faster than today. Today, in 45nm version, it reaches 60-70% of the speed of an POWER7. With 32nm version, it will be even faster. And then, only a few years later, it will be released in 22nm. POWER7 is developed far slower. In just a couple of years, x86 will be the fastest. And cheapest.
Thus, I think that to offer a full blown Enterprise Unix on x86 is a good thing. AIX is only available on expensive POWER7 gear. I predict IBM will port AIX to x86, or AIX will die. And HP will follow.
POWER managed with that slow cycle to stay well ahead of the barrage of new models you see in x86 turd land. How come?
intel has something crappy-as-in-x86 but pretty fast with the i7, which is quite an improvement over the p4. But it took them how many models and how many lines to overcome that little goof? I found myself wondering what the point of opteron nowadays is, but OTOH AMD is still offering decent kit in the value range, and they seem to survive well enough. Heck, the only reason atom exists is to push via's c3/c7 and AMD's geode range out of the market. With success (sadly), though I wouldn't be surprised if they're thin or even negative margin parts for intel.
Long term, I think MIPS might be back, only it'll speak Chinese: Loongson isn't there yet, but it's getting eerily close. And as long as the Chinese government figures it's something they want to have, well, can't argue with that sort of R&D backing. I tentatively welcome it because we so desperately need the diversity. If capitalism can't deliver... then what comes with this we basically only have ourselves to blame for.
You know, perhaps apple should stop buying up all the fabless cpu startups for a while and maybe we can have something fresh. With enough linux penetration there might actually be a viable market now. Not so much in the enterprise market, but with suitable lamp stack (or freebsd, nginx, postgresql instead) appliances one could carve out an interesting niche in hosting or even middle/small office markets. You'd have to raise a vertical stack of startups to make it happen, but perhaps some enterprising angel funders could try. There's an opensparc project to get the starting IP from, too. Oh yes dear, I'll get off me soap box and, yes, I'll take me meds now too. Thanks dear.
Re: Markk - Some do care
"Intel has plants and significant investment in Israel, who's lone ally is the US. Customers in neighboring countries prefer not to buy products made in a country that has a poor human rights record, starves residents of Gaza, and maintains apartheid policies towards Palestinians. I learned this important lesson when trying to sell our products to Saudi's."
I love that the Saudi's are concerned about human rights yet are quite happy to condone amputation, execution by stoning, and the exclusion of women from mainstream society (could be viewed as a societal apartheid of women).
What about the human rights records of the countries surrounding Israel - the ones that the UK fails to extradite terrorists to because their human rights "might" be violated.
Or maybe it was an excuse cos Galaxy's are lame compared to Proliant and X-Series?
Move everything to Sparc
You are clearly not in the real world if you think that Oracle could possibly succeed in dumping x86/64 support. Whatever the original architectural issues of Intel's processors, the leading edge of price/performance and, increasingly, power efficiency is being driven by commodity x86/x64 processors. For some workloads, then the Niagara is more energy efficient, but only for some, and it is crippled for others by having inherently slow processor cores (and one of those applications is quite a tot if high-end DB apps).
Apart from the Niagare, Oracle don't have a fast CPU; they have to rely on processors and servers designed by Fujitsu. Now whilst the SPARC64 is a fine chip, with fast single thread, good RAS features and highly scalable, it is expensive and uses a lot of power. It competes with Power and Itanium and is simply not a commodity chip.
A lot of companies now have a big investment in running Oracle on x86/x64 hardware, and are not going to look very kindly at any attempt to force a move to a processor architecture owned by Oracle. It simply won't happen or customers would just walk away. Whether Oracle continue with an x86/64 server line of their own manufacture or continue to make Solaris available on that that architecture is a slightly different thing (maintaining both Linux and Solaris support on x86/64 is expensive), but the day that Oracle decided to not provide future support for x86/84 in favour of Sparc would be the day that Larry Ellison would be lead off to a mental institution.
x86 vs SPARC
The SUN machines I have to work with daily are SPARC and x86 hardware. SPARC is slow as a dog, while x86 produces good performance.
I know all the arguments about x86 and RISC, but all I care as a software engineer is real performance and real reliability. SPARC is a sentimental leftover and should have been killed five years ago. Theory does not count, but real results.
Taking that as the decision criteria, SPARC is simply not competitive and it wastes MY time as a developer waiting for a find/grep or a make run.
And for all the non-niceties of X86 it runs very, very reliably and fast, if you use the right OS.
One of the most important elements of Frankfurt finance will switch to x86, Linux and C++ soon. And they do a lot of transaction processing in the millisecond time range.
No more SPARC, no Solaris, no Itanium.
re: x86 vs SPARC
"MY time as a developer waiting for a find/grep or a make run"
Funny... Your example of running slow are two single threaded, single purpose tools...
I agree that as a developer, SPARC is no longer preferred. Solaris X86, however is excellent
as a development environment. However, to turn out real world, high-end, applications that
run real businesses, you need a real, solid and reliable platform. Linux and X86 are not there quite yet. I can run an application on Linux 5 times and I'll get 5 different performance results. Granted, on low end boxes, those results are quite good, but they're all different. On high-end (over 32 cores), the randomness of performance is exacerbated. It's about running the applications - reliably - not how fast a "developer" can run find or grep.
However, if you indeed are looking for a find/grep processing box, then I highly recommend Linux on X64.
Oh yes, a "developer" argument
find, grep, and make are usually I/O bound. And single-threaded too, except for make if you ask it nicely.
If you care about quick compiling then C++ isn't the best choice. It's worse than C. C never was, really, which is why back in the day "we" used turbo pascal: Poor generated code but lightning quick compiling, and a reasonable dev environment fit on a 360kB floppy. It didn't need tons of include files, either, saving big on I/O again. C, by comparison, has always been rather slow and bloated, and survived by the grace of efficient pipe implementations on unix. Even so, code quality is not that important for, say, 90-odd percent (Knuth puts it at what, 97%?) of the code, and the last bits you first attack with the right algorithms, then with optimisation, and then with assembly. For numerical things you can often just pick the right library, which might be written in something else entirely, like FORTRAN. Though personally I start with organising my programs so that overall less needs to be done, and only after that it's time to worry about whether clever algorithms are needed, and only then try and pick the best one.
But I digress. Really, you may get a bigger speed boost from a decent SSD in your development station rather than switching CPU architectures.
What I've heard was the biggest problem in finance is the incessant time stamping, meaning lots and lots of syscalls. Millions of calls per second to time(). Yes, very smart, that. Just batch up a thousand transactions, push them all through, and timestamp them before and after. If the result is the same, fine. If not, well, what chip you got in there, a dorito? Either record the difference or mop up the damage if needed. Though the high frequency crowd will have moved to something with greater precision now. Wonder if they know the difference between accuracy and precision.
As mentioned elsewhere in the discussion, there's quite a difference between single threaded throughput and ability to run lots and lots of threads concurrently. For the former you have a reasonable one in x86, for the latter, not so much. For sparc, it's the reverse.
If you still believe more clockticks per second is heaven, I don't understand why you're even bothering with x86. Financials one expects to have the budget for POWER, which comes with a decent sack of threads too. Now to make use of them.
To illustrate: Suppose, hypothetically, and ignoring all sorts of important factors, you have an x86 that can run ten million trades a second per thread, and since it has four cores it can run fourty million trades all told. And suppose you have a sparc that can only run five million trades a second per thread, but it can run eight threads per core and comes in packages of eight cores. That's sixty four million trades for a dead slow sparc. Whoo.
Important factors ignored in the example include ten gigabit ethernet interfaces integrated on-die for the sparc t2, which can give much lower latencies than the x86 can for the next couple generations or so. Still think x86 will always win? It's got the biggest market share and therefore least incentive to innovate. You'd better pay attention to that sort of thing, dear developer, or you get out-quanted by some upstart with lower ping.
How many cycles does a single trade need anyway?
Now the Intel - AMD antitrust are over, some manufacturers going back to only Intel
Hi, when the antitrust laws were in progress, every distributor and manufacturer starting selling both AMD and Intel, looks like Oracle is now getting better pricing for shutting out Intel again, samo samo, here we go again!!!:( The are Oracle computers not Sun now...
x86 and virtualization
Resistance is futile.
Chip yields up, costs down. Compute capacity up, consolidation your only hope to harness the capacity. Think about. Think +15 years.
You are right that the C/C++ build process is inefficient and badly designed. But C/C++ is what management mandates to use and on Solaris I guess there are not many real alternatives if you want efficiently executing programs.
On the PC, Delphi or Lazarus would be a better choice. The whole "include" mechanism of C/C++ is broken, no doubt about that.
Theoretically Laazarus also runs on Solaris, but I never tried to use it. Anyway, mgmt would never allow to use it.
not just Opterons that are slowly disappearing ...
they seem to have spiked almost the entire bottom end of the range, and to be working to made it much harder to resell the rest of the range. Shame - having worked with HP Proliants, Dells, IBM x, and Sun's low-end servers, the Sun ones were by far the least troublesome I came across (for example,. compared with a customer's Proliant that used to reboot whenever anything else was plugged into the same pdu - nothing else on that strip had the same "feature", and supposedly redundant power supplies, going to separate PDUs, did nothing to stop it) and they were usually quite happy running hot (when you have to remove the cable management arms from the back of a poweredge to stop attached cables from melting, that's not a good sign; on the other hand a stack of ten x2100s sitting across the aisle just running quite happily at 25C ambient on the intake side)
x86 v SPARC v POWER - don't care. Well built and easy to manage servers going from market, it's just sad to see choices reduced yet again without any consideration being given to customers, partners or channel. That's the sort of behaviour one expects from Apple, not Sun. Can we have a pair of Larry icons please? Or maybe just the one, if things keep going this way.
x86 a computer game architecture
Intel's Atom shows how smart DEC engineers were for scheduling instructions in software - scheduling instructions at run time and band aids for a dated machine instruction architecture all consume thermal budget that could have gone to faster clocks, shorter pipelines, and more memory channels. Only recently has Xeon started to differ in a real way from desktop counterparts optimized for playing computer games. AMD lead with Hyper-channel and on-chip memory controllers, that Intel became forced to copy or be left uncompetitive. Alpha was to have massive memory bandwidth, and that is still a weakness of x86. Alpha was also free of all the slow CPU cache->I/O coherency bottlenecks x86 has for more simplistic programming.
After computer game graphics and computation, the next greatest sacrifice of best general purpose performance is to running inefficient languages and implementations faster. While Sparc and Power systems don't need to play games well, their systems performance must still satisfy inefficient web server-side scripts and baroque implementations. For example, the Java sandbox is important for untrusted code, but that's seldom the case. Large Java applications usually leak memory and are impossible to run weeks without a restart, unlike C applications.
My comments on Israel and Intel were to make a point that AMD is a needed option for those holding the expressed sentiments. Zionists should feel an equal right to boycott all petroleum products and byproducts: gasoline, heating oil, electric power generation, plastics etc.., along with any companies using these products of Saudi Arabia. Personally, I have many more Intel based systems than AMD.
- Geek's Guide to Britain INSIDE GCHQ: Welcome to Cheltenham's cottage industry
- 'Catastrophic failure' of 3D-printed gun in Oz Police test
- Game Theory Is the next-gen console war already One?
- Apple cored: Samsung sells 10 million Galaxy S4 in a month
- BBC suspends CTO after it wastes £100m on doomed IT system