back to article Fujitsu: Why we chose 64-bit ARM over SPARC for our exascale super

Fujitsu chose 64-bit ARM CPU cores for its upcoming exascale supercomputer for two reasons: Linux and the ability to customize its own processors. It was a bit of a surprise when the Japanese IT giant picked ARMv8-A over SPARC64 and x86 for its Post-K beast, which will be used by Japanese boffins to carry out climate-change …

  1. Brian Miller Silver badge

    And the next version of the Raspberry Pi...

    WOW! 512-bit SIMD! Oh, to have such toys! Isn't it nice when you can say, "meh, we'll just design our own processor, thanks."

  2. Anonymous Coward
    Anonymous Coward

    "ARM's larger and healthier software ecosystem?"

    People are compiling Fortran (and to a lesser extent C) to run on supercomputers, they're not using assembly. I guess he must have been talking about support from the Linux kernel community?

    1. Roo
      Windows

      Re: "ARM's larger and healthier software ecosystem?"

      "People are compiling Fortran (and to a lesser extent C) to run on supercomputers, they're not using assembly. I guess he must have been talking about support from the Linux kernel community?"

      Not just kernels, compilers, profilers and debuggers too. The CPUs shipped argument is pretty one-sided - and it is very unlikely to get better for SPARC because the players with mindshare (ie: Oracle) view SPARC as a cash cow, and they have a track record of actively fighting and sabotaging open source. None of that makes SPARC inherently bad but it does make SPARC harder to use.

    2. Charlie Clark Silver badge

      Re: "ARM's larger and healthier software ecosystem?"

      The irony here is that, up until a couple of years ago, Linux on ARM was pretty poor. The RPi has certainly helped here to get all the toolchains ported, tested and optimised though I reckon that nVidia has also contributed a lot as will the HPC owners themselves.

      1. Anonymous Coward
        Anonymous Coward

        Re: "ARM's larger and healthier software ecosystem?"

        I'd have to disagree that it was the advent of the RPis that advanced Linux development/porting on ARM and instead it was actually the state of Linux on ARM, especially with the advent of armhf, that made the RPis viable.

        Debian has been running on ARM since August 2000; the first RPis were released in February 2012.

      2. Anonymous Coward
        Anonymous Coward

        Re: "ARM's larger and healthier software ecosystem?"

        "until a couple of years ago, Linux on ARM was pretty poor."

        Maybe the household names didn't have ARM support, but in the small and not-so-small embedded systems Linux world there were plenty of Linuxes (commercially supported and otherwise), some of them more than capable of providing all you need for a compute-oriented node. I used to use MontaVista simply because that's what the hardware/box vendor supported, but other options were readily available.

        Whereas neither Intel nor SPARC had (or probably will have in the foreseeable future) any significant presence in the compute-node market. Intel's NextUnitofComputing [1], or this quarter's hot SoC from an ARM partner? It's not really a difficult decision for most people even if Windows is currently a pre-requisite (which is a bit rare in the HPC world, despite several years of MS trying to strongarm people into using Compute Cluster Server 2003 and then Windows HPC Server 2008 and friends).

        [1] http://www.intel.co.uk/content/www/uk/en/nuc/overview.html

  3. jms222

    Haven't we forgotten about how many concurrent SIMDs the thing executes ?

    Otherwise just stating the width is pointless but is rather like the modern trend of being fixated on the number of cores (which end up 99% idle for most of us).

    1. Mage Silver badge

      how many concurrent SIMDs the thing executes ?

      Lots or many, I think, thinking of entire computer, not a chip. My brain needs cooled to count that far.

    2. Anonymous Coward
      Anonymous Coward

      Supercomputer applications are designed to scale across thousand of cores - so unlike PCs those cores are not idle!

      1. Roo
        Windows

        "Supercomputer applications are designed to scale across thousand of cores - so unlike PCs those cores are not idle!"

        They still wait on I/O like any other CPU, the speed of light still has an impact on how code is written and networks are built. ;)

        1. Anonymous Coward
          Anonymous Coward

          "They still wait on I/O like any other CPU"

          If an HPC application spends much time waiting on IO then someone needs to call in a real HPC expert to give the setup a once-over, because that's a total waste of time (as you rightly point out).

          1. Anonymous Coward
            Anonymous Coward

            What versiion of windows will it be running?

          2. Roo
            Windows

            "If an HPC application spends much time waiting on IO then someone needs to call in a real HPC expert to give the setup a once-over, because that's a total waste of time (as you rightly point out)."

            Define "much" ! :)

            How does a "real HPC expert" magic up no mem-waits on a 16 core Xeon running sparse matrix code with a 16 way set-associative shared L3 cache ? The killer micros have taken over, they are a lot faster than the beasts that came before them - but equally it's also much harder to extract peak performance from them with apps that feature large memory footprints. I'm not having a dig, just pointing out that some problems are inherently awkward. :)

            1. Anonymous Coward
              Anonymous Coward

              "it's also much harder to extract peak performance from them with apps that feature large memory footprints."

              At one time the answer might have been to look for a cache-friendly implementation of the algorithm(s) in question (or, alternatively, a different algorithm for the same requirement).

              At one time a good place to start looking for cache-friendliness in many cases might have been the Kuch and Associates, Inc's preprocessor(s), a source to source transformer that understands the behaviours of particular algorithms and particular target processors and can make the most of available resources without requiring too much expertise on behalf of the user/programmer (e.g. by automated parallelisation for use on multi-core systems).

              So far as I recall, Intel bought KAI and took the preprocessor off the market, and people mostly stopped buying chips other than x86 for serious numbercrunching (exceptions apply). The techniques are still valid, whether they're relevant or not is a different question, and who needs expertise when the people that really care (financial traders etc) just throw money at the problem and buy weird hardware (e.g. FPGA-based coprocessors and such).

              "some problems are inherently awkward"

              Ain't that the truth.

    3. DaLo

      Since most businesses, of a size suitable to have someone in IT working for them, has moved to a virtualized infrastructure then their cores should not be sitting 99% idle or they haven't sized their system very well.

      1. Roo
        Windows

        "Since most businesses, of a size suitable to have someone in IT working for them, has moved to a virtualized infrastructure then their cores should not be sitting 99% idle or they haven't sized their system very well."

        If you run VTune on the bare metal you will see lots of expensive cache misses where the CPU is sat twiddling it's thumbs waiting for memory to catch up. In old school super-computing this wasn't an issue because the core clock speeds were similar to the *random access* latency of the memory subsystem (and the applications + OS were tuned to maximize page/cache locality.

        "Virtualized Infrastructure" workloads are actually particularly rough on caches and TLBs, their memory access patterns are much more random - they are nowhere near as kind to the memory subsystems as a well tuned HPC workload. Consequently the cores spend a lot of time idle waiting for memory to catch up, and in this scenario the OS will report the CPU being 100% busy - if you want to find out how much of that 100% busy is spent waiting for memory you'll need to run VTune or something like that. I wish these kind of stats were more readily available to end-users and sys-admins - the CPU occupancy figures are pretty much meaningless these days - they just tell you when the run queue is exhausted and nothing useful about how busy the system really is. :)

  4. Tom 7 Silver badge

    Selling Arm is starting to look like a dumb move for all concerned

    apart from the buyer in the long term.

    1. paulf Silver badge

      Re: Selling Arm is starting to look like a dumb move for all concerned

      I agree, but I guess that's how Segars and Co extracted a non-trivial 43% premium over the pre-approach share price from Softbank.

      1. Tom 7 Silver badge

        Re: Selling Arm is starting to look like a dumb move for all concerned

        As a shareholder I'm going to make a short term killing but in the long term I think I would be better off to keep it independent - as would the market and future users. In the long term 47% looks completely shit for a company that has doubled in price in 3 years and is opening new markets across the board.

    2. anonymous boring coward Silver badge

      Re: Selling Arm is starting to look like a dumb move for all concerned

      I recognise the tendency from when Swedish companies sold out to whoever. The country will suffer in the long term. So annoying that domestic investors are so weak and uninterested (stupid).

  5. Paul Crawford Silver badge

    SPARC future?

    What will this mean for Oracle & SPARC in the long term if Fujitsu has decided to move away from it?

  6. Ilsa Loving

    Sparc may as well be dead

    With the way Oracle has handled pretty much everything they have ever gotten their grubby little hands on, I expect everyone will be ditching SPARC as soon as economically viable. Why would any right-thinking person willingly choose to be beholden to a company that likes abusing and suing their customers?

    1. Anonymous Coward
      Anonymous Coward

      Re: Sparc may as well be dead

      Does OpenSPARC still exist? Is it still relevant?

      1. ArtFart

        Re: Sparc may as well be dead

        Short answer: No, and no.

        Longer (and snarkier) answer: Who knows, and who cares?

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

Biting the hand that feeds IT © 1998–2020