Ellison: Sparc M7 is Oracle's most important silicon EVER

Re: Nice

the licence fee is only 150 BEELION dollars

Or one new yacht for poor, hard up Larry...

Re: Nice

"With memory protection, you can discover those bugs really early"

Congratulations on finally copying Intel NX.

" is by handling compression in silicon – specifically on the decompression side."

Congratulations on copying Intel QuickAssist....

"but the company is still investing in the Sparc processor technology it acquired when it bought Sun Microsystems in 2010."

Presumably Ellison needs something to anchor his yachts to the sea bed....

Re: Nice

Yeah. It's gonna be pricy.

If you were going to spec a brand new database system tomorrow it's quite hard to justify Oracle (or IBM for that matter) with their pricing.

Not impossible mind, but if they keep it up it may well be unless you are in the Fortune 100.

Re: Nice

So much negativity.

I'm sure all those Itanium sites out there will be looking to move to SPARC M7's when they realise there aren't going to be any more performance bumps on the Itanium road map....

Cat... Meet pigeons...

Re: Boastful bravado

Mmmmmm.

This is interesting as the chip seems much more like a Sparc T than a Sparc M. Guess they're either getting confused or mashing the lines together. Either way, they realised a while ago that 64MB of L3 for 32 cores is way too low for a big database machine and more like the ratios seen in the Sparc Ts, which then got a core drop to increase this ratio for Sparc Ms!! Having had experience of Sparc Ts running certain workloads, I can certainly say you have to be very careful with them as single thread performance really sucks. Critical thread helps, but then you loose a lot of supposed 'benefit', so go figure.

He also likes boasting about facilities that other manufacturers have had for years. As has previously been said, Power has had memory compression for years and has also had memory keying, which is similar to his memory protection. Overall seems like an awful lot of hot air and random boasting about anything and everything.

Re: Boastful bravado

The announcement appears to be an acceptance that Sparc is no longer a general purpose processing chip but something optimised for running Oracle applications. Admittedly that's an awful lot in the application space - it's not just databases of course. However, it does seem a retreat from what SPARC was once mooted to be. A high-speed RISC general purpose, cost-effect, CPU that could compete on all aspects of performance and suit a wide range of applications.

Of course the real problem is that the T series essentially gave up on single thread performance in favour of increased aggregate throughput. It's a bet that applications will be developed to suit this architecture. As many of us found when deploying T series machines (often bought by senior managers who swallowed SUN's line of power efficiency, throughput and virtualisation), they were fundamentally crippled for some sorts of applications. It often showed itself up where latency was an issue. Call centres are expensive to operate, and keeping agents (and customers) hanging around for slow systems is not efficient.

As it is I would not choose SPARC except for reasons of supporting legacy applications.

Re: Boastful bravado

It has improved greatly since then but everything about it shouts "excessive yet deficient". 32 cores sharing 64 MB of L3 is just 2 MB of L3 per core. Appears to be at least a 3 Hop if not 4 Hop design from a core in Socket A to a core in Socket B. That results in NUMA behavior and latency. 2 TB Ram per socket which is 64 GB per core vs 170 GB per core on a 2 socket S824 - that's important when heavy virtualization is used.

You proceed from a false assumption - this isn't x86 commodity hardware. If you think about it in those terms you're going to come to completely inaccurate conclusions. Virtualisation? Diversified app loads? If that's the road you are taking you'd be a mug to take this when x86 can do the same thing for 20% of the cost. No, this is big iron for big jobs - centralised processing of things that can't be split over a number of machines, yet alone run on a small percentage of a machine in a VM.

In that context the cache is more than fine: the cores are going to be largely working from the same data set, but even if they are on different tasks a simple division of the cache among the cores is not enlightening given the law of diminishing returns and the radically different cache utilisation of a diversified load.

I did work at what was then Sun up until about six years ago, albeit on firmware, and I can tell you that those specs will not have been plucked from thin air. They do an awful lot of research when arriving at the headline features, not market research to keep the box tickers like you happy, but proper scrutiny of the loads their customers are actually placing on the hardware and where the real bottlenecks are. If you compare this to x86 running x86 style loads it'll work fine but lets face it, it's hardly going to be cost effective. Instead you specify something like this for loads that would bring x86 to its knees, in which case there is simply no comparison to be made.

Re: 32 cores, eh?

> 2. licensing? ouch Ouch and OUCH. Try licensing an Oracle DB for 32 cores. Yeah....

This hardware is perfect for ZFS. hardware compression acceleration will be part of ZFS.

You don't need to run on all available cores DB engine but on access to huge amount of compressed (transparently from application point of view) data you will need a lot of CPU power to compress/decompress these data. Data deduplication is next which is consuming relatively huge CPU power.

You can assign to Solaris project only few cores and pay only for CPU power which needs you database.

Re: Memory Protection

And well before that in S/360.

Re: Memory Protection

What's different between the features a standard MMU has and Larry's new toy?

Details seem to be scarce online, but I ran across one quote that mentioned memory keys, so it does appear to be similar to IBM's POWER6 storage protection key mechanism.

It's basically a limited version of a capability architecture - you can assign page protections that are associated with a label, not just global ones, and then only (hardware) threads that hold the corresponding "key" get those permissions.

Conventional MMUs assign page permissions globally, and the kernel sets them on a per-process basis, so your protection granularity is the process. Storage keys let you change the protection granularity to threads and thread groups.

Of course a real capability architecture (AS/400, arguably Burroughs MCP, etc) is much fancier.

Re: Lot of ignorance from the IBM crowd here

trying to trash talk and spread negative rumours of the SPARC M7 cpu. For instance, say that the M7 memory protection new functionality is nothing more than an ordinary MMU. Well, if you read the released information, instead of speculate, you would see why it is not an ordinary MMU:

https://blogs.oracle.com/ask-arun/entry/in_memory_query_acceleration_of

The second link has no mention of memory protection that I can see. It just talks about the hardware decompression.

The first link has this to say:

On the Java front, the Sparc M7 has new memory protection features and virtual address masking that will make Java garbage collection easier and more deterministic, according to Fowler. [snip]

The S4 core, for instance, has special instructions to ensure application data integrity, which is done in real-time and which safeguards against invalid or stale memory references and buffer overruns for both Solaris running C and C++ applications and the Oracle database.

Which says bugger all more than the El Reg article.

I'm not trying to bash (pardon the topical pun) Oracle or you, MadMike. I'm genuinely interested in what Oracle (claim to) have done to improve security.

Re: Lot of ignorance from the IBM crowd here

"trying to trash talk and spread negative rumours of the SPARC M7 cpu. For instance, say that the M7 memory protection new functionality is nothing more than an ordinary MMU"

In fairness the quote from Larry didn't exactly spell out what was new or different from anything that had gone before. If you understand the difference you could spell it out for the folks who want a bit more substance than Larry's content free blather.

"let us see IBM POWER8 do 120GB/sec querys."

Nah, let's wait and see if M7 boxes actually show up and do this first in independently conducted repeatable and verifiable tests, after all Larry has incentive to lie and exaggerate his product's performance, and we can't trust anything you say because you keep comparing SPEC to SPEC rate figures... Come to think of it you keep ignoring any SPEC rate figures that beat the SPARCs as well.

"Well designed specialized hardware accelerators are typically >10x faster or so."

You really shouldn't have bothered making that comment, it's content, context and fact free.

"For instance, compare GPU vs CPU."

GPU = executes thousands of short lived threads with very few branches/conditionals, extremely regular memory access patterns, low-medium single thread clock rate...

CPU = executes code with a branch/conditional every 3-6 instructions, highly irregular memory access patterns, very high single thread clock rate.

"And the SPARC M7 is 4-5x faster than the SPARC M6. Let us see the benchmarks, until then you can continue spread the FUD and negative made up rumours."

While we're waiting for some independently verifiable benchmarks, it would be great if you could pop over to spec.org and learn how their benchmarks work so you don't make the mistake of comparing the rate figures to the single core figures again. It shows a lack of professionalism that reflects poorly on you and the products you push so vehemently.

Re: Lot of ignorance from the IBM crowd here

"And regarding the "awful" performance of the SPARC M7, well, let us see IBM POWER8 do 120GB/sec querys."

But I can go buy a Power 8 CPU today.....

Re: Lot of ignorance from the IBM crowd here

You complain of FUD then respond with not only FUD but you also are flat out lying in your attempt to disparage Power technology. Criticize the technology but spell it out rather than broad and sweeping statements.You demonstrate an anger that goes beyond competitive differences. You cite TPM, here is a recent article from him on the performance of Power8 vs x86 and SPARC. http://www.itjungle.com/tfh/tfh092914-story02.html

Re: Lot of ignorance from the IBM crowd here

"So you choose, 32-socket POWER7 or 16-socket POWER8 - you will not get better performance by choosing POWER8. So what is the point of POWER8"

In this case, cheaper licensing costs. One reason Power eroded Oracle on Sun hardware over the years is the Power perf was so much better even with the "factor", Sun made a lot less sense to run Oracle. I've been part of a migration , a huge migration from Sun to Power, migrating to a lot fewer cores and saving a bunch on Oracle licensing costs.

Re: Well

Yes it is a good idea to bake own hardware. The point is that these M7 servers are targeted to the largest workloads, that x86 can not come close.

There are workloads where a cluster does not cut it. For instance, to guarantee database transaction integrity over many nodes is very very very very difficult. It is much easier and cheaper to buy one single large SMP server instead, than solve a difficult problem that no one has solved before. Synchronization messages over a cluster are slow, to nodes far away in the cluster. A tight SMP server is much much faster.

So if you need a x86 server, you are not the primary Oracle DB customer. Then MySQL might suit you. If you have the largest workloads then you are very interested in completing the work in hours or even minutes, instead of never finishing. Yes, JP Morgan executives were astonished that some queries even finished at all on the largest Oracle SPARC servers.

Re: Get back into the HPC market

I quote myself again:

"...There are workloads where a cluster does not cut it. For instance, to guarantee database transaction integrity over many nodes is very very very very difficult. It is much easier and cheaper to buy one single large SMP server instead, than solve a difficult problem that no one has solved before. Synchronization messages over a cluster are slow, to nodes far away in the cluster. A tight SMP server is much much faster..."

Oracle is interested in Enterprise business market, that is where the big money are. Business. Not research and development as HPC clusters do.

For business, you can only run them on a large SMP server. Clusters wont do it. Clusters are only good for embarassingly parallel workloads. SGI explains that their large Linux Altix and UV servers can only handle HPC cluster workloads. In short, they are clusters, or behave like clusters. You can not run SGI in Enterprise business. For that you need single SMP server, like Unix or Mainframes. The largest Linux server on the market has 8-sockets, everything larger than that are Linux clusters. So for Enteprirse business you need 16 or even 32 sockets. No Linux there.