Oracle To Debut Low-Cost SPARC Chip Next Month 92
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.
Licensing (Score:5, Funny)
In related news, Oracle have also announced a new per-transistor licensing model.
Re:Licensing (Score:5, Insightful)
With 32 cores, this chip must have the Oracle licensing people very excited
Re: (Score:2)
You don't think Oracle would allow something to be designed which didn't maximize license revenue, do you?
Why, yes, we'll sell you this CPU for $800 ... but the licensing costs for your organization running this in production in a web-facing environment will be 16 trillion dollars.
Oracle is all about maximizing license revenues.
One Rich Asshole Called Larry Ellison. It costs a lot of money to maintain private islands and yachts.
Re: (Score:2)
Re: (Score:2)
Yes, but Oracle currently charges licensing based on the number of cores you are running their software one, databases in particular.
The massive number of cores in this chip (and transistor count increases with core count) would lead to large licensing fees, unless Oracle creates a means to limit the cores that their product runs on based on licensing
In the 90's it was pretty popular to tie application licensing to a CPU ID, I wonder if something similar would come into play here
Re: (Score:3)
What do you wanna bet Oracles new sparc chip includes functions that automatically call home and report on violations of obscure licensing provisions that someone may not have realized they violated.
How timely... (Score:3)
Re: (Score:2)
And yet they still support POWER. Odd.
https://www.debian.org/ports/p... [debian.org]
Re: (Score:3)
And yet they still support POWER. Odd.
https://www.debian.org/ports/p... [debian.org]
It's not odd at all [google.com].
Re: (Score:2)
Absolute POWER corrupts everything.
Re: (Score:2)
Re: (Score:2)
Anyone left outside Oracle that uses Sparc now?
Today it's x86 or ARM that are worth to be concerned about.
Re: (Score:2)
Re:How timely... (Score:5, Interesting)
Horse hocky. My Nexis 7 rolled over and died a few weeks ago so I had to scare up a replacement tablet. I choose Asus Z580C to replace it. This tablet has a intel atom Z3530 processor in it, which I found out later is a x86 based processor.
I've had it for 2 weeks now and I've very pleased with it. To say the x86 can't be used well in a mobile processor is grade a bullshit.
Re: (Score:2)
x86 is probably going the same way as Sparc. x86 is powerful but too powerful to be used on mobile devices and doesn't scale very well on desktops when it comes to parallel processing.
Intel continues to work on reducing power consumption of x86 while retaining performance.
ARM continues to work on increasing performance while retaining low power consumption.
I'm hoping for everybody to win.
Re:How timely... (Score:4, Interesting)
SPARC and POWER still have a place. There are some computing tasks that can't really be split up among multiple nodes, so they still require gigantic CPU requirements. Usually this is related to legacy databases which cost less to keep on the legacy architecture than spend the time to try to move it to PC clusters.
Another use for SPARC and POWER (and to a lesser extent, ARM) are security applications. In theory (and this is theory, mind you), if another F0 0F bug is found on the x86 platform, perhaps giving attackers remote access to ring 0, having multiple architectures will help mitigate the effects of it.
Of course, with SPARC and POWER, virtualization is an integral component of both platforms, and for some tasks, it just might be the case that slicing off a lot of LPARS and zones may be cheaper than buying a lot of PCs and using a VMWare cluster, due to the license fees involved.
Re:How timely... (Score:4, Interesting)
MIPS is another arch with staying power, mainly because of being largely patent-free. Opencores has VHDL. [opencores.com] IIRC, China has come up with some functioning clusters based on this and there are design wins to be found in embedded (e.g. Broadcom). I don't think there is really anything special about MIPS that makes it attractive. A servicable but unexciting architecture with some programmer-visible quirks that cater to ancient design assumptions that lost validity long ago. MIPS isn't going to die because some embedded designer is always going to find it the cheapest way to chip their product.
Re: (Score:2)
And don't forget, competition is good. Single sourcing leads to technical stagnation.
StackGhost (Score:1)
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 sys
Re: (Score:2)
"There are some computing tasks that can't really be split up among multiple nodes, so they still require gigantic CPU requirements. Usually this is related to legacy databases which cost less to keep on the legacy architecture than spend the time to try to move it to PC clusters."
True but what does that have to do with the usage of Power/Sparc? There do exists 32 and 64 processor xeon systems, and sgi will even sell you a system with 256 cpus and 64 TB ram if you can pay the price.
https://www.sgi.com/produ [sgi.com]
Re: (Score:2)
"Performance per watt" is a bullshit metric...until you have to pay the electric bill.
Re:How timely... (Score:4, Insightful)
Yes, ESA (European Space Agency) uses SPARC, but another implementation (LEON2 and 3, fault tolerant versions [1] ). And NGMP[2] I think is also SPARC based.
LEON is developed by Gaisler, and was funded by ESA.
Alvie
[1] https://en.wikipedia.org/wiki/... [wikipedia.org]
[2] http://microelectronics.esa.in... [esa.int]
Re: (Score:1)
Re: (Score:2)
Re: Oracle (Score:3)
What? (Score:2)
[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.
Re: (Score:1)
[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.
This processor includes encryption support... An ISA that no one uses!
Re: (Score:1)
You don't know what you're writing about. And the SPARC V9 ISA is great: one instruction cycle for every instruction, free instruction slot for any instruction after a branch, zero cycles. 32 64-bit registers, 256 virtual 64-bit register with the hardware register windows. Flat memory model. Great performance, especially for hand written assembler code, unbelievably fast.
Oh, and did I mention UltraSPARC is great? In case I did not, it is great. Because the ISA is really slick. Because it rulez!
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
And I don't think they're referring to "text" and "data" pages since that has been in Sparc since before the V8/V9.
And, if I recall, the VAX and BSD before that - I seem to remember futzing around with those for the linking loader project in my systems programming class that used our VAX-785 running 4.3BSD back in the mid 1980s. (Yes, I'm old.)
Re: (Score:2)
Re: (Score:2)
I see you never begged at the feet of Silicon Graphics....
Sun on a throne? Sun were amateurs compared to SGI in making your customer kneel.
Re: (Score:2)
I don't think Fujitsu, Texas Instruments, Atmel, or Cypress Semi would agree with you on the opulence of the SPARC architecture. It has had a very vibrant community of licensors for a long time. The hyperSPARC, TurboSPARC, and SPARC64 VI aren't even Sun products, to name a few.
Re: (Score:3)
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.
Re: (Score:2, Insightful)
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.
Re:Good Job Everyone, Congratulations (Score:4, Informative)
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.
Re: (Score:2)
"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.
Competition is good (Score:2)
.
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.
Different Processor, Same Problems (Score:2)
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
Re: (Score:2)
Low cost chip, high cost support (Score:5, Interesting)
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.
Re:Low cost chip, high cost support (Score:4, Interesting)
My naive expectation would have been that SPARC on such liberal terms would show up a bit more often embedded in various chips that need some sort of CPU to do housekeeping, as the ISA of security and/or nationalism driven 'indigenous technology' efforts, and potentially even as the cheaper-than-ARM option for application processors.
Clearly that hasn't actually happened, and it's mostly ARM in SoCs and application processors(with PPC holding out in certain automotive and networking niches for some reason; and MIPS in router SoCs and the occasional Chinese vanity project); so ARM's license fees must just not sting that much.
Building SPARC parts that go toe to toe with Xeons would obviously be a much more ambitious project(as well as an act of directly fucking with Intel's juciest margins, which they probably won't take very kindly); but I am surprised by the fact that SPARC is so rare among the zillions of devices that have no need for x86 compatibility and are mostly about delivering performance in the gap between beefy microcontrollers and weak desktops for as little money as possible.
Re: (Score:2)
Sure the ISA is open, but that is just for the CPU. A meaningful inplementation needs all the stuff that goes around it, and, as with all electronics, volume is king.
Theoretically, as you say, someone who needs a CPU to embed could choose Sparc. Then they could set about developing the rest of the system. But when they place an order, they better have a vlome market - or they would be better of with an alternative by a very large margin.
The existing Sparc
Re: (Score:2)
Now if a Sparc product was to target the mobile phone market?
Yeah, there's already been embedded SPARC processors, I talked to some guys at a job fair a long (long) while back who had built a digital camera around one. The problem is, they're just not cheap enough.
Re: (Score:1)
https://recon.cx/2014/slides/Recon%202014%20Skochinsky.pdf
It's dead Jim (Score:3, Informative)
It's dead Jim. [debian.org]
That's the debian verdict. Oracle may have other ideas, but if drinking that koolaid, caution is advised.
Re: (Score:2)
Somebody modded my post troll, almost certainly an Oracle employee. However, the linked mail is a fact, and the current situation is a fact, no astroturfing will change that. To you the mod: sad to be you.
An idea for Oracle (Score:2)
"at the end of the month" (Score:2)
Translation for ordinary people (Score:4, Funny)
Instead of costing an arm and a leg, Oracle's new chip will only cost you a couple fingers and a toe.
But there would be no need for this chip (Score:3)
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.
Sparc is dead! (Score:2)
Long live Sparc!
Wait, what?!?
Re: (Score:2)
No, I am Sparctacus!
Re: (Score:2)
Spa-rtacus?
Spar-tacus?
Spart-actus?
Sparta-ctus?
Spartact-us?
Re: (Score:2)
Read it again.
It's Sparc-tacus.
Oracle wanted it to die (Score:2)
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
Why? (Score:2)
Re: (Score:2)
Well, it was more than one market. Mainframe, minis, open systems, embedded, home, small business (channel), office, manufacturing, supercomputing, etc.
Some markets completely disappeared, other markets were overrun by players that expanded beyond their britches.
Capacity and performance wise, x86 could have ruled the roost already in the 90's, the only reason the *Nix vendors still had market share was strongly held myths about performance, and that it is an expensive undertaking to move off legacy software