back to article Seventh-gen SPARC silicon will accelerate Oracle databases

Oracle will soon detail the SPARC 7 architecture, and how it includes new in-silicon features designed to make Big O's databases and applications achieve better performance in an all-Ellison environment. John Fowler, Oracle's executive veep of systems, today told The Reg that the company will reveal details of the new silicon …

  1. bazza Silver badge

    Good to see SPARC being updated still; I hope it does well.

    Making SPARC good for their database is a natural thing for them to do. IBM do the same for their POWER processors, which have features that are good for international financial applications. For really big systems that sort of thing can make a significant difference to the power bill.

    HP aren't able to do the same anymore; Intel must surely be super reluctant to do anything to Itanium. I notice that most of the op codes that gave some sort of benefit to Itanium have now found their way into Xeon, I expect Itanium to go no further, and HP will become just another x86 box shifter with a crummy line in 19" rack rails.

  2. Anonymous Coward
    Anonymous Coward

    Can anyone explain? I'm genuinely curious.

    I'm not a 'big iron' bloke. In fact I've unfortunately never been anywhere near those sorts of machines.

    As much as it's clearly to everyone's benefit to have a competitor to x86, I don't understand what the business case is for investing in SPARC equipment. Wouldn't x86 be faster, cheaper and better supported for any sort of workload at this point? Will Oracle be expecting to pick up new customers for SPARC 7, or will the buyers pretty much just be existing customers unable or unwilling to migrate away from existing SPARC deployments? If it's the latter, wouldn't it be better to take the opportunity to migrate to x86 instead (and avoid having to deal with Oracle so much as an added bonus)? Is there any kind of task that SPARC is the obvious choice for?

    Honestly, if anyone can explain this stuff, I'd truly like to understand.

    1. Keith 21

      Re: Can anyone explain? I'm genuinely curious.

      Depends upon what your task is.

      Fast-as-possible single threaded performance, or a small handful of simultaneous threads?

      Yup, x86 will do you right there no questions.

      High performance very highly threaded simultaneous applications?

      How does a box capable of scaling from 1 thread to 2048 threads, and up to 32TB (yes TB) of RAM, all viewed by the software as a single system without having to recompile for different numbers of threads grab you?

      Guess which one high-end large databases will run better on...

      And that's with the current SPARC technology, who knows what SPARC 7 will offer.

      It all depends upon your tasks.

    2. bazza Silver badge

      Re: Can anyone explain? I'm genuinely curious.

      "As much as it's clearly to everyone's benefit to have a competitor to x86, I don't understand what the business case is for investing in SPARC equipment. Wouldn't x86 be faster, cheaper and better supported for any sort of workload at this point?"

      Power Consumption

      As Keith21 said, it depends on your tasks. For some really, really big tasks, 'cheaper' means cutting the power bill and forget everything else. And if your enormous task requires a lot of one sort of operation to be performed it's worth optimising that in silicon because you can slash the power bill. On a really big setup power is lots of $millions a year, so a few expensive boxes that can halve that are worthwhile.

      I don't know much about databases, but I know a little about IBM's POWER. They added a decimal maths co-processor, i.e. a core extension that does maths much as you would do it on paper. This is very different the traditional floating point unit in that it has (so I understand) arbitrary precision. What's the point?

      Well, when you're doing calculations for international finance you're basically doing currency conversions, which are floating point math. And if you're dealing in $Billions, conventional floating point arithmetic isn't accurate enough; you can be a few cents out. That's unacceptable. So the software has to do the math long hand.

      Doing that on x86 takes forever (= a lot of power used), whereas on POWER there's a co-processor that does it far quicker. And if you're building the foreign exchange system for an entire country that's a big enough system for you to be worried primarily about power consumption as your major cost. And having the system scalability as Keith21 explained means that you can do the whole job in one machine at high efficiency.

      And guess what; one of IBM's big markets is banking. Oracle's big market is databases. They're both doing elaborate things in their silicon to target very specific markets.

      What is Memory?

      It's quite interesting to examine what 'memory' is nowadays. Although we talk about 32TB of RAM in some sort of SMP configuration, actually it's synthesised from high speed internal networks (not Ethernet, at least, not yet) between processor nodes and memory controllers. This sort of architecture has percolated down to x86; Intel has QPI and AMD uses Hypertransport. These are similar in concept to current mainframe architectures, it's just that they don't scale up to thousands of cores.

      If you ever start hanging round the HPC world you quickly realise that most of it is all about I/O speed, not CPU speed, provided the CPU is basically 'right' (and Oracle's announcement is basically about getting the CPU right; they did the I/O ages ago). Get the I/O right and you can pile up the CPUs until you have the necessary performance. Get the I/O wrong and you cannot do that. This was the reason why AMD briefly had the upperhand over Intel when Opteron first came out; Hypertransport was way better. For a good example of getting the I/O right take a look at the K computer and its six dimension hypertoroidal interconnect, and note how power efficient it is.

  3. Mad Mike

    Resiliency Model

    Before investing in any Sparc servers, I would suggest people look at the resiliency model and exactly what happens on certain failures. You might be surprised (just had my replies back from Oracle!!). What appears to be a resilient server looks like it relies quite heavily on the application configuration (i.e. Oracle RAC etc.) to achieve resiliency, rather than making sure the server can take failures.

    I was genuinely shocked to hear what is considered acceptable for component failure according to Oracle.

    1. Stretch

      Re: Resiliency Model

      This has nothing to do with SPARC

      1. Mad Mike

        Re: Resiliency Model

        @Stretch.

        Care to elaborate? Why does a comment about Sparc servers have nothing to do with Sparc processors. I'm confused.

        1. Mad Mike

          Re: Resiliency Model

          PS @Stretch.

          I do appreciate that I'm talking about the server and not the processor directly, but bear in mind the attributes of the server are often at least partially driven from the processor. So features and limitations in the CPU (SPARC) design could well be causing some of the lack of resilience I have talked about. I'm still diving into it with Oracle and don't have full details, but some of the resiliency issues I'm investigating seem to be related to the PCI bus design, which is very CPU related.

          1. Down not across

            Re: Resiliency Model

            I'm still diving into it with Oracle and don't have full details, but some of the resiliency issues I'm investigating seem to be related to the PCI bus design, which is very CPU related.

            Well, there certainly are design issue especially when it comes to virtualisation where for example T4 didn't allow for very resilient design as it had only one PCI root complex, whereas T5 has two and thus enables more complete virtualisation of the hardware which makes a difference since Oracle's current resiliency model tends to revolve around virtualisation.

    2. Phil O'Sophical Silver badge

      Re: Resiliency Model

      What appears to be a resilient server looks like it relies quite heavily on the application configuration (i.e. Oracle RAC etc.) to achieve resiliency, rather than making sure the server can take failures.

      Why does that matter? For most users the important thing is the resilience of the system as a whole. Whether an appropriate level of resilience is achieved in hardware alone, or with co-operating hardware and software, is just an implementation detail.

      Certainly you can make very resilient hardware like Tandem & its ilk, at a substantial cost in redundant subsystems. Do you always need that? Statitstically, very little system downtime is due to hardware faults, most is human error and software problems. Few applications need bleeding-edge resilience-at-any-price hardware, for a given application youi'll need a certain level of resilience, and what's important is to provide that at an appropriate price point.

      1. Mad Mike

        Re: Resiliency Model

        @Phil O'Sophical.

        I do agree to a point. Not everything requires that very high level of resilience. However, as you rightly point out, most downtime is due to human and software errors. So, for those solutions requiring high levels of resilience, the last thing you want to rely when a hardware fault occurs, is software!! You're relying on one of the lowest reliability components to provide said resilience.

        Anyone who has had any experience with clustered database systems will know how often the clustering doesn't work as expected or planned.

  4. Fenton

    Are these the SPARC or the T processors

    I've had nothing but scalability problems with the T range of processors.

    Whilst they look good on paper with loads of threads, we have found that for a heavily loaded

    transactional systems, they perform like a dog.

    Why they are great when you have lots of parallel processes that require very little CPU power,

    but if you fire 256 threads reasonably heavy threads at the thing it just stalls giving very slow performance per thread with unhappy users.

    A CPU that is less threaded (i.e. regular SPARC), we've found it far more efficient for the software thread to wait until the faster core becomes available and users are happy as their transactions runs in a decent time.

    1. Mad Mike

      Re: Are these the SPARC or the T processors

      @Fenton.

      This is exactly surprising and has been known for some time. Essentially, the cache per core/CPU is nowhere near as big as competing processors. This leads to issues with cache flushing etc. when switching between threads and more memory access and therefore lower throughput. If you look at the Sparc M chips, they have higher cache levels at the expense of fewer cores.

      1. BlueGreen

        Re: Are these the SPARC or the T processors @Mad Mike

        > This leads to issues with cache flushing etc. when switching between threads and more memory access and therefore lower throughput

        I thought that the later sparc chips had hardware threading with round-robin thread scheduling exactly for hiding read latency - many slow threads somewhat 'immune' to ram read delays. (am not a chip guy though)

        Separately,

        > Chipzilla has, for example, made sure recent Xeons are tuned to the needs of workloads like Hadoop

        Have they? And how would one tune a chip for such loads? To my knowledge there's nothing specific to hadoop that that the chip architects could focus on. It's heavy on IO, its heavy on java, it's heavy on sorting... but that's nothing unique to hadoop. I'm really puzzled.

    2. Keith 21

      Re: Are these the SPARC or the T processors

      It'll be the SPARC M series (the M7), not the T series, given this is for high-end stuff. Not that this rules out announcing the T6 as well, but from the description they are absolutely talking about the M7 here.

    3. Down not across

      Re: Are these the SPARC or the T processors

      I've had nothing but scalability problems with the T range of processors.

      Whilst they look good on paper with loads of threads, we have found that for a heavily loaded

      transactional systems, they perform like a dog.

      This is not exactly news.

      However to give Oracle some credit, the T-series has gotten better with each iteration. T5 (and to largee extent T4) are much better than their predecessors. Not perfect by any means, but considerably improved.

    4. regadpellagru

      Re: Are these the SPARC or the T processors

      @Fenton

      "Whilst they look good on paper with loads of threads, we have found that for a heavily loaded

      transactional systems, they perform like a dog."

      That's because the Niagara series (T) has been designed for apps that are light on the communication bus (App servers, web servers, mais relays) and very parallel, not for heavy DB servers. For this, you should use other gear (Power 7 from IBM or M series from Oracle).

  5. Down not across

    SPARC 7?

    So, we're going from current SPARC V9 to SPARC 7 ..very logical.

    1. Anonymous Coward
      Anonymous Coward

      Re: SPARC 7?

      Substantially more logical than (super|ultra|hyper|turbo)SPARC + random roman numeral + random other letters.

  6. Mac Attack!

    Actually, the SPARC T4 and T5 systems are the best selling SPARC servers ever by volume. Since SPARC T4 introduced the concept of dynamic threading and critical thread support in Solaris, the poor single-threaded performance of the past T1-T3 CPUs is no longer an issue. There are plenty of public benchmarks that demonstrate how the T4/T5 perform and scale better than the Intel or AMD CPUs. Sun was the first to really embrace SoC (System on a Chip) in a commercial processor. Modern SPARC CPUs have PCIe controllers, memory controllers, cryptographic engines, coherence links for SMP, etc. all built into the CPU. Intel, AMD, and even IBM are all playing catch up to Oracle and Fujitsu on this front. Intel has relied too much on clock frequencies and this is why their performance has only improved ~15% if that. Meanwhile, SPARC performance has improved on average at least 2X with each generation since the acquisition. Oracle has done some great things with the investment in SPARC and Solaris.

    Being able to scale up performance linearly to 32 CPU sockets on an SPARC M6 or 64 CPU sockets on the M10-4S is a pretty big accomplishment. Both of those systems scale up to 32TBs of RAM and a boat load of PCIe slots. They can be broken up into physical or logical domains for consolidation or run as a single system. Can't do that with x86 :) Those large systems are used by banks, e-commerce sites, governments, healthcare, insurance, etc companies who need the compute power on their back end systems (ERP, CRM, Financials, etc.). The T4/T5 servers scale up to 8 sockets and are used by companies to host web services, middleware, databases, etc. Most of the enterprise software out there is based on Java and is highly threaded, so they scale really well on SPARC. But with the T4/T5, the heavy single threaded apps are now performing well on SPARC.

    The challenge for server manufacturers in the UNIX market (Oracle, IBM, HP) is that you don't need as many servers to replace old servers anymore. It's very easy to replaced an E25k with a small T4 server. It's not uncommon to see Solaris and AIX shops doing some extreme consolidations. The number of OS instances has not decreased in many sites, if anything they have gone up. The difference is that the number of physical servers had gone down significantly thanks to virtualization. This is the same problem that HP, Dell, and IBM have been struggling with since the introduction of VMware. I've been on many projects over the past 6 years where sites that had hundreds of UNIX servers have consolidated to a few racks of modern SPARC and Power servers. You just don't need as many physical servers anymore.

    VMware, Linux, and x86 has been an impact, but if you look at what applications have moved in that direction, it's not the bulk of the business critical systems. It's the low hanging fruit which takes up the majority of the traditional data center (dev/test servers, web servers, IDM, middleware, print services, VDI, etc.). Things like CIFS/NFS shares for home directories and applications that use to be on UNIX and Windows servers have by far been replaced by NAS appliances. But when you get to the mission critical systems, where the money is really made in a business, it's usually going to be on a UNIX server or a mainframe.

    You would be surprised to learn how many of the services you take advantage of in everyday life are back-ended and in some cases front-ended by SPARC and Power servers. Some of the major ones are banks and e-commerce sites all of us use every day.

    FYI.. SPARC v9 is the ISA version, not the CPU version or model number :p

  7. chasil

    The Oracle DB soars on SPARC

    Oracle planned a boutique, high-performance architecture for their database, and they delivered.

    http://www.theregister.co.uk/2012/10/01/fujitsu_oracle_athena_chip_server?page=2

    "I am going to make a promise to you," Ellison said. "By this time next year, that Sparc microprocessor will run the Oracle database faster than anything on the planet."

    The highest SPARC benchmarks are now an order of magnitude over the competition:

    http://www.tpc.org/tpcc/results/tpcc_perf_results.asp

    Larry kept his promise.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like