back to article U wot M8? Oracle chip designers quietly work on new SPARC CPU

Oracle engineers are seemingly working on a new SPARC processor: the M8. This is judging from a series of patches submitted by Oracle developer Jose Marchesi to the widely used free-as-in-freedom compiler toolkit GCC. The code "adds support for the SPARC M8 processor to GCC. The SPARC M8 processor implements the Oracle SPARC …

  1. Mark Solaris

    "support for using the new misaligned load/store instructions for memory accesses known to be

    misaligned at compile-time."

    Awesome... that will allow shitty structs to be handled so we don't get SIGSEGV's. Hand tuning them was getting old.

    1. Anonymous Coward
      Anonymous Coward

      shitty structs

      A correct compiler will pad structs to ensure that all members are aligned for their data types, that's been a requirement since K&R days. You should never get a SEGV when referencing the address of a struct member, on any architecture.

  2. Daniel B.

    Me likey

    Any going forward with RISC non-Craptel stuff is good. :)

    1. Anonymous Coward
      Anonymous Coward

      Re: Me likey

      Yeah man! Can't wait to pay those lovely guys at Oracle many times the price of a Xeon system that performs just as well or better in many cases and then get gang raped per socket for software that actually does something interesting with it.

      < insert meaningless drivel about how Intel's stuff is based on an 8 bit architecture, CISC is bad because RISC is good because *reasons*, Itatium being a flop etc>

      1. Loud Speaker

        Re: Me likey

        If you dislike Solaris, and Oracle's databse bugs, you are welcome to use OpenBSD and Postgresql. Your data might even be more secure that way.

        Unfortunately, Oracle do not appear to contribute much to OpenBSD, and in particular, don't seem to want to reveal how to use their hardware crypto acceleration, so I fully support the point that Oracle are scum.

        1. Stevie

          Re: Me likey

          It is naive to suggest that PostgreSQL can replace Oracle database product stacks, unless those Oracle databases are small, uncomplex, stand-alone deployments.

          If that is the case in your enterprise you should already have done it as a trivial swap and be deep into mitigating all the downstream assumptions that were found to be untrue in fact.

          Our enterprise is wedded to the RAC/Dataguard model for reasons that stray into other vendors' product lines, both software and hardware.

          Besides, I was fooled into attempting to adopt MySQL (for a small project then using MS SQL Server) years ago based on promises of features that were documented but not properly implemented in the software, for a complete and utter fail. First and last time I followed "everyone knows" wisdom.

          I've learned by experience to treat such claims of equivalency with a very large pinch of salt.

          1. Justin Clift

            Re: Me likey

            > Besides, I was fooled into attempting to adopt MySQL ... based on promises of features that were documented but not properly implemented in the software, for a complete and utter fail. First and last time I followed "everyone knows" wisdom.

            "Everyone knows" MySQL is mostly a toy database, unless your needs are replication of simple data types and you have the staff at hand to manage it's problems. Not sure why you bothered trying it for a different purpose.

            PostgreSQL on the other hand is not a toy database. As you mention, it's also not a complete replacement for Oracle. It's more featureful, reliable, and well engineered than many parts of Oracle with the exception of replication. There's no complete "one size fits all" replication solution in PostgreSQL, though many projects exist specialised for different replication scenarios. The PostgreSQL Community is generally pretty friendly, helpful, and welcoming too, which is good when the shit hits the fan. :)

        2. patrickstar

          Re: Me likey

          I don't really see a reason why you'd run something other than Solaris (or illumOS perhaps) on SPARC outside some very specialized applications and stuff that just refuses to compile on it.

          And you'd probably do that in a VM/LDOM.

          Really - Solaris is very, very good for Very Important<TM> stuff.

          In fact, I'd bet Solaris would be a good choice of an OS to run Postgres on. It's certainly a very good choice for MySQL.

          Security wise at least the kernel itself isn't worse than any of the other systems to the extent it would be a reason to choose one over the other.

          Memory protection/exploit mitigation is on par with Linux nowadays, but perhaps a bit weaker than OpenBSD (I haven't kept up with what OpenBSD has implemented or not).

          And Solaris has a very powerful ACL/RBAC system too.

          (I wouldn't recommend giving untrusted users the ability to run code on Solaris of course, but I wouldn't recommend that for any of the others either, at least not out of the box without custom mitigations and voodoo.)

      2. captain_solo

        Re: Me likey

        The smaller S7 series is priced right where the Intel systems are with pretty similar core counts. Even the higher end systems are competitive from a price/performance perspective if your workload sizes up to it, mostly people leave 80% or more of the capacity idle so the complaints are more about the planning than the gear. These systems tend to be used for pets instead of cattle so that drives more idle system capacity and more replication for HA/DR. Not really sensible to compare that to adding a system to your VM farm for "normal" apps where you don't care about performance or service levels and you oversubscribe everything till it hurts.

        On the software side, agreed, its pretty rough going either way, but there are actually some advantages going with SPARC in certain design cases where you would need more licenses on any other platform. Especially if you want to use virtualization.

      3. PlinkerTind

        Re: Me likey

        @Daniel Palmer

        Actually Sparc M7 is up to 11x faster than x86 on business workloads. It is the worlds fastest cpu, typically 2-11x faster than Xeon and Power8.

        Sparc M8 willagain double the performance. X86 has no chance.

        Look at the largest SAP benchmarks, all top spots are sparc and Solaris. X86 does not scale, it stops at 8-sockets 16-socket results are bad). If you need the largest business workloads, you must go to large risc 16- or 32-socket servers. Just chech SAP and see x86 scales bad. All top spots are sparc on large 16- or 32-socket servers

  3. John Smith 19 Gold badge
    Unhappy

    Perhaps they've discovered the hardware is more important than they realized?

    Just a thought.

    Hmm. "Misaligned structs."

    Sounds like something you'd want if you were trying to port code from other architectures, without forcing a re-write of the source code.

    Which is exactly what you'd want to do if you wanted to encourage (potential) customers to migrate to your architecture.

    1. Paul Crawford Silver badge

      Re: Perhaps they've discovered the hardware is more important than they realized?

      As already mentioned, a normal compiler will align structure members to avoid this sort of problem.

      Unless you use some packing directive to override that sort of thing, and most commonly that is done for faster/simpler binary file access. So it could be to run other CPU's software more simply, or it could be to speed access to binary data created for/used by another CPU architecture.

      Either way it is nice to see the SPARC is not totally dead, just a shame it is Oracle and their eye-watering prices, licensing terms, etc, in the way.

  4. John Smith 19 Gold badge
    Unhappy

    "So it could be to run other CPU's software more simply, "

    Exactly.

    I'm reminded of the oft made claim that Windows is as big as it is because it's got lots of "special case" code because various hardware mfg ship either faulty hardware or poorly implemented drivers and each has a chunk of Windows code to deal with it, rather than force the mfg to do it right.

    This drops that thinking down to the hardware level

  5. Anonymous Coward
    Anonymous Coward

    News?

    seemingly working on a new SPARC processor: the M8

    Well, it's not like they didn't say so themselves back in March, for Oracle's own compiler:

    http://www.oracle.com/technetwork/server-storage/developerstudio/overview/developer-studio-beta-program-3654693.html

    "Oracle SPARC M8 pipleline scheduling and optimization"

  6. Anonymous Coward
    Anonymous Coward

    Scale

    It's an issue of market size and scale. Sparc and Solaris are showing their age. Only the fact that Larry treats them as the jewels to his kingdom keeps them alive. Intel/AMD simply have too much market share for Oracle's niche offerings to have much relevance.

    1. bazza Silver badge

      Re: Scale

      What's age got to do with it?

      There's features in Solaris that Linux is still trying to replicate. ZFS is one of those.

      Sparc/solaris clearly matter to enough people to make comparisons to Intel / Amd / Linux / Windows irrelevant. They want it, Larry's selling it. Or maybe Fujitsu are.

      IBM is similar. There's enough niche applications for which mainframes based on POWER are ideal to be worthwhile making them. For example POWER, with its decimal maths coprocessor, is fantastic for currency exchange calculations. Some people want to do a lot of those ultra reliably every day of the year.

      1. Anonymous Coward
        Anonymous Coward

        Re: Scale

        In a cloud and microservice era ZFS advantageover ext4 or xfs is irrelevant simply because you place your workload on a top of other clustered block storage system like EBS or Ceph. And this underlying block storage system is providing you all the capabilities you may want to have like reliability and checksums, snapshots, synchronous or asynchronous replicas etc. From my perspective ZFS is irrelevant unfortunately.

        1. Justin Clift

          Re: Scale

          > In a cloud and microservice era ZFS advantageover ext4 or xfs is irrelevant simply because you place your workload on a top of other clustered block storage system like EBS or Ceph.

          Except if you're the one providing the block storage. ZFS provides useful capabilities (checksums, snapshots, backups) on the backend. :)

        2. patrickstar

          Re: Scale

          I'm sure that, after you're done playing with your "stack" of shiny toys and/or get fed up with the latest fads and need to actually get stuff done, you'll appreciate ZFS too.

        3. PlinkerTind

          Re: Scale

          I doubt any filesystem except zfs, provides good data integrity with checksums. Btrfs is a piece of shit,so it doesnt. In fact, Lustre was rewritten to not use ext4 as backend because of data integrity issues and scalability problems. Instead Lustre is using, you guessed it, zfs as backend. Lustre is better than ceph,says some people

      2. pyrasanth

        Re: Scale

        Mainframes based on Power?

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