Slashdot Mirror
Five Years After the Sun Merger, Oracle Says It's Fully Committed To SPARC
jfruh (300774) writes "Sun Microsystems vanished into Oracle's maw five years ago this month, and you could be forgiven for thinking that some iconic Sun products, like SPARC chips, had been cast aside in the merger. But Oracle claims that the SPARC roadmap is moving forward more quickly than it did under Sun, and while the number of SPARC systems sold has dropped dramatically (from 66,000 in Q1 '03 to 7,000 in Q1 '14), the systems that are being sold are fully customized and much more profitable for the company."
It should be: around the time of the acquisition the price performance ratio finally got back to where it was with the first SPARCs: ten times the price, 100 times the performance .
A 3U 4-socket T5 machine had about 128 full hardware threads (really: cores) the last time I looked seriously at it. The performance was a bit less than a 32-socket, 4-core-per -socket M9000, the machines I mostly worked with. In those days, I was a capacity planner and performance engineer at Sun Canada.
A lot, but not everything, is still available open-source from SPARC International.
--dave
davecb@spamcop.net
The killer feature is portability and snapshot/template. You can clone machines quickly and move them to new hardware seamlessly (with the right licenses and backend). You can also make quick snapshot backups to backout changes or clone to new systems. With the right scripts you can scale up your cluster sizes dynamically.
Cheap storage VM.
If you examine the top two best performing database platforms (as benchmarked by TPC-C score) you will discover that they are both sold by Oracle, and that the SPARC version has both higher performance and a lower cost per transaction than the x86-64 version.
You might find this quote to be particularly interesting:
AIX 5L+? Minimal porting? You've very obviously never actually done it.
The total extent of IBM's efforts with AIX 5L was to put RPM 3.0.3 on their systems and build a few RPMs. The underlying source base for your RPM better support AIX or you're in for a good deal of fun. And you know what? Pretty much everybody dropped AIX support years ago for, I might add, very good reasons. AIX is a Unix, but a seriously weird one. Oh, and by the way, can you guess the version of RPM shipped with the latest AIX? Clue: it begins with 3. Check out the versions of packages at http://www-03.ibm.com/systems/power/software/aix/linux/toolbox/alpha.html. Most/all are seriously old. Many are a decade or more out of date.
As someone who has to deal with targeting AIX (as well as Linux), from my developer PoV AIX is dead, dead, dead. And starting to smell very very badly.
Meanwhile, Oracle have something like, what, 28k system sales per anum on which to amortize the cost of SPARC development? Pity. I loved old Sun kit, but sorry, SPARC is walking dead too. Just like AIX and POWER.
From a general standpoint, very little - which is why their numbers have dropped from 66k to 7k in 11 years. They are apparently used to build systems still compatible w/ legacy Solaris systems, which is what enables their high margins. Otherwise, more than 64-bit, Intel's multi-core architecture, and the fact that it is several process nodes ahead of the SPARC, gives it a big advantage at the same price point, not to mention its support for several more modern OSs, such as Linux, BSDs, Windows Server 2012, and more. If you don't have a legacy SPARC establishment, there's no reason to go that route.
As Intel found out w/ Itanium, the traditional disadvantages of CISC - wrt not only VLIW, but RISC as well - are obliterated: Merced originally resulted in only a 10% savings in die size - certainly not worth the complexity in the compilers and other costs incurred in building that platform. And once Intel tossed more cores into a CPU to scale up its performance, overtaking any other RISC CPU at the same price was no longer an issue. Especially since every OS for it - Windows, Linux, *BSD - support it
Fore disclaimer: I'm employed by Oracle.
My duties at Oracle have always been developing Mac and (more recently) iOS Apps. So I end up using Apple hardware. That aside, all developers have a remote unix account for development. We host server instances of the particular product we develop for, and have other such servers for hosting a number of dev tools. Many of those servers are hosted on "Sunacle" (my term) hardware.
In the Mtl office, we also have a bunch of Sun stations in various places like some local server rooms and demo/training rooms.
Sun is *everywhere* around me. Oracle has a huge investment in Sun (both in hardware optimisation and Java) which led to the acquisition 5 years ago. Was more of an investment rescue than a growth acquisition, if you ask me. BUT I DO NOT KNOW for sure if my point of view & assessment is what really led to the acquisition. Developers are not privy to such details.
A 3U 4-socket T5 machine had about 128 full hardware threads (really: cores) the last time I looked seriously at it. The performance was a bit less than a 32-socket, 4-core-per -socket M9000, the machines I mostly worked with. In those days, I was a capacity planner and performance engineer at Sun Canada.
Okay, but it's not a one-for-one comparison. A hardware thread in one of those machines lies somewhere between an x-86 "core" and a GPU "core" in capability.
Granted, they were powerful machines. But a 128-thread SPARC machine has nowhere near the capability of a modern x86 machine with 128 cores.
Solaris/SPARC is still going strong in large companies. One of the greatest advantages it has is that Oracle creates and supports the operating system, and Oracle creates and supports the hardware. (If you're running an Oracle database or some other piece of software, then that's an additional component that they create and support.) What this means is that if I'm having a problem, mundane or esoteric, I can go to one vendor and say, "Fix it." There isn't any bickering about what company's problem it is, and who manufactured my RAM, or any other the other silliness that crops up in vendor support. Large companies value this (as do us sysadmins). That also means they can do some very cool software tricks (which I'll mention a few here below).
The decreasing unit shipments is just as much a sign of virtualization as anything. Right now, I'm looking at an older T5240, with two eight-core CPUs which presents itself as having 128 virtual CPUs (execution engines or thread engines), and 64gb of RAM. This is by no means the biggest box on the floor. We carve these up into smaller systems using either Solaris Zones, or LDOMs. That's two different methods of virtualization with two different goals.
I did something great with an LDOM last week. I took a virtual server that was on the box and migrated the entire operating system and all the applications over to another LDOM... WHILE IT WAS STILL RUNNING. Aside from a quick (1 second) pause, the applications on the server had no idea that it just migrated to another piece of hardware while it continued to run. Slick! The original server had a failing DIMM. No worries, though even aside from ECC, the operating system automatically mapped out which parts of the DIMM were defective and retired the pages of memory so that they weren't constantly being exercised. Linux does all that... right? No?
Someone else, above, said, "I don't think you can have a zfs system fail and move it to different hardware like you can with vmware...". Nevermind that we can migrate a running operating system and application to another piece of hardware and keep it running. Yes, of course if you have a hardware fault, you can bring it back up on another machine. The virtualization with Solaris is quite capable.
In the environment of a large company where we're competing against Linux on the low-cost end of things, Solaris/SPARC is not only holding its own, but actually beating our Linux cloud counterparts in the costs of a virtualized OS/hardware. (I should ask my boss if we can publish a paper on this, because it is rather impressive.)
On the high end of things, we completely dominate. We generally use a T5-4 for our internal cloud (which really isn't the biggest Oracle server out there). It has 64 cores, presenting 512 execution threads to the scheduler. RAM goes up to 2TB. If someone starts out on a tiny box with only one CPU and 4gb of RAM, we can scale them all the way up to the top by increasing their virtualization settings. No migrating to different or unusual hardware. If an application team can't scale their code horizontally (hey, it happens), they can go way vertical in this configuration. We haven't had a need yet for an M6-32 (32tb of RAM, and 32 of the 12-core CPUs (3072 execution threads or "virtual cpus"). We have Linux surrounded (on the low-cost side and the high-performance side) in a large enterprise environment, and that's why Solaris is still there.
Now, I'm not an Oracle salesperson. But if Slashdot ever did an AMA with an Oracle sales engineer, I think my fellow Linux admins would be particular impressed on how far ahead Oracle/SPARC is in a number of key areas.