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 …
"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.
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.
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.
"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
"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. :)
"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.
"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. :)
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.
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?
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
