Slashdot Mirror
Oracle To Debut Low-Cost SPARC Chip Next Month
jfruh writes: Of the many things Oracle acquired when it absorbed Sun, the SPARC processors have not exactly been making headlines. But that may change next month when the company debuts a new, lower-cost chip that will compete with Intel's Xeon. "Debut," in this case, means only an introduction, though -- not a marketplace debut. From the article:
[T]he Sparc M7 will have technologies for encryption acceleration and memory protection built into the chip. It will also include coprocessors to accelerate database performance.
"The idea of Sonoma is to take exactly those same technologies and bring them down to very low cost points, so that people can use them in cloud computing and for smaller applications, and even for smaller companies who need a lower entry point," [Oracle head of systems John] Fowler said. ... [Fowler] didn’t talk about prices or say how much cheaper the new Sparc systems will be, and it could potentially be years before Sonoma comes to market—Oracle isn’t yet saying. Its engineers are due to discuss Sonoma at the Hot Chips conference in Silicon Valley at the end of the month, so we might learn more then.
In related news, Oracle have also announced a new per-transistor licensing model.
Just in time for Debian to drop support.
"National Security is the chief cause of national insecurity." - Celine's First Law
Thank God for Oracle, the world's number One technology company!
[T]he Sparc M7 will have technologies for encryption acceleration and memory protection built into the chip.
Well, encryption acceleration has been available on x86 for a while and memory protection has been available on... well, I seem to remember that was the big feature the 286 had over the 8086, and it was only new to PCs at that point. That's a rather peculair thing to brag about, especially as the SPARC chip has always had it since it's inception.
Whatever though. I am kind of in two minds about this. Yaaay cool new sparc chip! ew, Oracle.
SJW n. One who posts facts.
For many corporations oracle may as well be the Eye of Sauron, and absorbing one of the most opulent chipsets around certainly didnt help. SPARC was so expensive to own, so protracted to license, that only multinational conglomerates dared approach the throne of SUN. Once oracle bought them out, SPARCitecture owners were confronted with an even more monolythic corporation that could neither agree upon how to continue licensing, nor could provide additional contractually ensured hardware and software to a pretty powerful collection of customers. So customers who hadnt moved to x86 in 2010 were suddenly presented with an excellent incentive to do so.
Small businesses though? never had that problem. most looking to cut rising licensing costs had moved to x86 by the mid nineties (or SGI if they still wanted jaw-dropping performance.) by 2007 SUN was pushing rope; x86 had proceeded to x64 and most applications were running fine. multicore, distributed, and load balanced architectures had been developed and been in existence thanks to the GNU ecosystem of FLOSS for 6-7 years already. SUN shuffled their IP to Oracle and shuttered the doors of a once proud computer company.
sparc, the oracle boot environment, virtualization, you name it and x86 will do it cheaper and without the burden of recompiling everything. Sure, linux runs on sparc but far more development has proceeded in the X64 and emerging ARM platform than Oracle can ever hope to evolve from their sparc offering.
Good people go to bed earlier.
.
On the other hand, Oracle still has the unquestioned ability to shoot itself in the foot with the predatory pricing models apparently associated with it.
Cost & Support! From the summary, this is described as a new effort to bring the SPARC processor cost down to where it can compete with Intel's high end parts.
High cost + no installed base = flop (megaflop?)
I remember back around 2002 when we got a fancy SPARC server at work that was multi-processor, big ram sun fire. The thing cost in the neighborhood of $40k. We also got an x86 server for about $2500 at the same time. When I ran large circuit simulation jobs on the x86 server, they ran about twice as fast as on the sun. Oops! Now, maybe this processor is more competitive with its performance, I don't know, but I don't think the situation has changed significantly.
Sell it on an ATX motherboard, maybe with dual-CPU support, DDR3 or DDR4 RAM, and support PCIe video and I might be interested.
They can bring it back to life if necessary.
I'm sure the hardware itself will be cheap. Oracle's hardware is like IBM's mainframes -- they'll practically give away the hardware if you'll burn up MIPS on a regular basis. Even if "give away" is thousands per socket, it's a drop in the bucket compared to the fees for support and any OS licensing. Our relatively large company is a decent sized Oracle DB customer (lots and lots of hosted J2EE enterprisey applications) and the maintenance fees alone, just to be able to run the software, are eye watering.
The problem is that licensing like that keeps all but the most well heeled customers off SPARC, and hence the popularity will never get much higher than it is. Ever since Linux on x86 became a viable alternative, companies without a real need to run SPARC and by extension Solaris on SPARC are migrating away. Even Debian dropped support for its SPARC port.
Whether it's the high cost keeping people off SPARC, or the niche nature of Itanium keeping people off Itanium, a system architecture needs a critical mass of customers with a continued need to run on it to be successful.
Too little, too late.
It's dead Jim.
That's the debian verdict. Oracle may have other ideas, but if drinking that koolaid, caution is advised.
When all you have is a hammer, every problem starts to look like a thumb.
Before you get all jumpy, I would suggest you wait and see what Oracle means by "low cost". I will bet that their "low cost" is something that most companies still can't justify little alone an individual.
The parent comment should not have been modded down.
It highlights an important problem: the Debian project has been making one truly bad decision after another recently.
We all know about Debian's systemd disaster. It was an absolutely stupid move that seriously divided the Debian community, and forced many of its best users over to the BSDs and other OSes.
They also pretty much killed Debian GNU/kFreeBSD near the end of last year.
This more recent SPARC nonsense from them is yet another failure on their part.
Instead of making the project better, these actions have just caused it harm.
Debian's utility has become nearly non-existent for those running serious servers, and even workstations, where boot problems caused by systemd are just not acceptable.
The loss of these other platforms and architectures now makes Debian more of a monoculture, which experience shows is never a good thing. Diversity and choice are good for a large-scale software project. They bring together people with different ideas and different needs, which results in more reliable and robust software system across all of the platforms and architectures.
It's truly saddening to see how Debian, which did so much good for so many years, has hit such hard times lately, with pretty much all of this suffering being self-induced.
If they want to do a hardware thing, they should invest the time in making a multicore processor which solves a problem no one else is solving. Maybe a processor specifically designed for microkernels and untrusted code. Maybe an FPGA that implements CAM's + complex SQL functions on the fly in circuitry, as needed? You know, stuff people other than Oracle might actually have a use for? Then they could sell that stuff and make money.
As I can see, the article was posted on Friday July 31, 2015 (not sure whether Slashdot is showing me local time)... So it's today?
Instead of costing an arm and a leg, Oracle's new chip will only cost you a couple fingers and a toe.
Live today, because you never know what tomorrow brings
"Potentially years" before the vaporware product of undisclosed cost that probably won't draw any interest if it is ever released. This is just oracle trying to sound like they haven't given up.
This space intentionally left blank
If only Oracle revised their licencing policies.
It is impossible to build a cost-effective production ready system with industry standard components, such as proliant blades, vmware, etc, because of only 1 thing: Oracle's hostile licensing policies and metrics. First is the 25 users minimum per processor license. Then there is the fact, that you have to license the full physical server, unless you deploy on very specific Oracle VM hypervisor configuration. And these days, you can't get blades with less than 4 cores. SO if you need a few Oracle software products, you will easily spend more than half a million. So now we have all these shops, trying to streamline their IT into easy to provision private clouds, only to find out that they have to toss it all away.
-- Another senseless waste of fine bytes.
Long live Sparc!
Wait, what?!?
Harrison's Postulate - "For every action there is an equal and opposite criticism"
The SPARC ISA also supports a novel stack-smashing prevention technique that ARM, MIPS, POWER, and x86 do not: StackGhost.
https://en.wikipedia.org/wiki/Buffer_overflow_protection#StackGhost_.28hardware-based.29
It's used by default on OpenBSD. Here's a slide from a presentation Theo deRaddt did about 10 years ago:
http://www.openbsd.org/papers/auug04/mgp00026.html
If you're a C or C++ developer and you're serious about code quality, you could do worse than focus on portability; portability across operating systems as well as portability across CPU architectures. Compiling and executing your code in different environments can do wonders for identifying bugs and problem areas. Of course, portability doesn't mean you only stick to ISO C or strict POSIX. You don't need to support every system under the sun; you use your best judgment. But a little portability work and testing goes a long way to improving a code base. In addition to stress-testing your code, it makes you think twice about depending on fancy proprietary compiler features, build tools, or poorly maintained third-party libraries that only work on Linux or Windows. 9 times out of 10 those things will eventually turn into liabilities, because if nobody else thinks they're useful enough to adopt, that's a strong signal they might be half-baked. And understanding how APIs differ across platforms provides insightful contrast to the APIs on your preferred platform, which helps you to judge how to appropriately leverage them, and how they might evolve in the future.
I was a big SPARC fan. I've still got two old Sun Netra sparc64 1u servers in my basement. I used to have used sun workstions, and even had MidnightBSD running on some Sparc64 systems early into my project.
The problem is that when Sun was sold to Oracle, they closed up patches, documentation on old hardware and anything useful for supporting old Sun hardware. That meant that the used market dried up. They then put out only super expensive systems and got rid of workstations. This caused developers to lose access to modern systems and most ports of Linux and BSD gave up over time. Now you have to run Solaris on Sparc and you pay a lot of money to do so.
It's just not worth it. Solaris has lost momentum due to these moves. Everyone moved to Linux or BSD. It's over guys. Just give up and push Oracle databases on Linux and Windows now.
MidnightBSD: The BSD for Everyone
It doesn't matter how much better any new CPU design is. Unless you've got a billion dollars a year to invest in making it better, you're simply not going to keep up with Intel, and it will soon be obsolete. And unless you're selling hundreds of millions of copies of that CPU, you likely don't have a billion dollars a year to invent in R & D. Unfortunately, CPU chips are a textbook case of a "natural monopoly" i.e. "A natural monopoly is a monopoly in an industry in which it is most efficient (involving the lowest long-run average cost) for production to be permanently concentrated in a single firm rather than contested competitively." Sure, Sparc was cool when it first came out. Now, it's just a curious anachronism.
I've abandoned my search for truth; now I'm just looking for some useful delusions.
It highlights an important problem: the Debian project has been making one truly bad decision after another recently.
We all know about Debian's systemd disaster. It was an absolutely stupid move that seriously divided the Debian community, and forced many of its best users over to the BSDs and other OSes.
SPARC support was killed because there where no developers to maintain it. Debian doesn't have fat support contracts that enables the project to hire developers to support legacy architectures. So if a software project/package/architecture isn't supported by developers so that bugs get fixed, it will be killed off.
systemd was widely welcomed by almost all Debian developers and the vast majority of Debian end-users. There was a lot of noise of the Debian mailing lists when the decision was made, but it turned out that the tiny minority of systemd-opponents couldn't even muster 5 Debian Developers to sponsor a GR to overturn that decision.
They also pretty much killed Debian GNU/kFreeBSD near the end of last year.
Again, look at the Debian mailing list. There where practically zero Debian GNU/kFreeBSD developers active, meaning that bugs didn't get fixed, even release blocker bugs. Even Debian GNU/Hurd was a vibrating developer hub compared to kFreeBSD and probably had many more end users too.
If you want something in the open source world, you will have to contribute towards it, either by code, bug reports, translations/documentation or money. Both the SPARC architecture and kFreeBSD failed to receive enough of such support to survive.
Notice that Debian will continue to support SPARC on existing pre-Jessie SPARC releases, just not on future ones.
The may "support" it, but without updates to OpenJDK on SPARC there is no compeling reason for me to use Debian instead of OpenBSD on Sparc64.