Slashdot Mirror
Japan's Fujitsu and RIKEN Have Dropped the SPARC Processor in Favor of an ARM Design Chip Scaled Up For Supercomputer Performance (ieee.org)
Japan's computer giant Fujitsu and RIKEN, the country's largest research institute, have begun field-testing a prototype CPU for a next-generation supercomputer they believe will take the country back to the leading position in global rankings of supercomputer might. From a report: The next-generation machine, dubbed the Post-K supercomputer, follows the two collaborators' development of the 8 petaflops K supercomputer that commenced operations for RIKEN in 2012, and which has since been upgraded to 11 petaflops in application processing speed. Now the aim is to "create the world's highest performing supercomputer," with "up to one hundred times the application execution performance of the K computer," Fujitsu declared in a press release on 21 June. The plan is to install the souped-up machine at the government-affiliated RIKEN around 2021. If the partners achieve those execution speeds, that would place the Post-K machine in exascale territory (one exaflops being a billion billion floating point operations a second). To do this, they have replaced the SPARC64 VIIIfx CPU powering the K computer with the Arm8A-SVE (Scalable Vector Extension) 512-bit architecture that's been enhanced for supercomputer use, and which both Fujitsu and RIKEN had a hand in developing. The new design runs on CPUs with 48 cores plus 2 assistant cores for the computational nodes, and with 48 cores plus 4 assistant cores for the I/O and computational nodes. The system structure uses 1 CPU per node, and 384 nodes make up one rack.
For many years my daily driver was a M3000 Fujitsu 4 core 2.86Ghz SPARCVII with 64GB of RAM and a internal RAID disk running Solaris 10. It still would be too had my employer not moved to a combination of Windows and Linux. Very reliable, scalable, hardware and OS.
No
FTA: "30 to 40 megawatts..."
"first, a feeble spark, next a flickering flame, then a mighty blaze, ever increasing in speed and power." - Nikola Tesla
SVE is a flexible in terms of vector length, with maximum width of 2048 bits. The 512 was likely selected due to power, bandwidth and chip real-estate reasons. We should know more after the Hot Chip representation, available free for everybody at this December the latest.
"SVE is a flexible in terms of vector length, with maximum width of 2048 bits."
AVX can get wider too if it makes sense. The fact that an exotic purpose-built supercomputer chip that won't be in real operation until 2021 is clearly taking design cues from a 2017-era consumer-grade part that you can use to play video games kind of shows how this nonsense about "ARM" vs. "x86" doesn't mean anything in the real world.
Incidentally, for all the crap about "RISC" that gets tossed around here like a magic get-out-of-thinking-free card, anybody who actually knows what RISC actually means would tell you that any and all SIMD units violate RISC's principles.
AntiFA: An abbreviation for Anti First Amendment.
K was listed at number 10 in Nov-2017 benchmark and about 1/9th the speed of the fastest machine. But on HPCG benchmark (http://www.hpcg-benchmark.org ), it was listed number 1. Even now, it is number 2 behind the Summit in HPCG. Not bad for a computer debuted in 2011. Hope they can maintain performance on HPCG as well.
The proposed computer's LINPACK power efficiency is good but not that impressive. Summit is 8.8 MW and proposed computer is 8 times faster at about 4-5 times power consumption. So efficiency increase by a factor of 2 in 3 years (it is expected to be ready by 2021).
"anybody who actually knows what RISC actually means would tell you that any and all SIMD units violate RISC's principles."
No, SIMD units do not "violate RISC's principles" and your saying so only demonstrates your own shallow understanding of what these principles are. RISC may mean "reduced instruction set computing" but that doesn't mean the end game is the smallest instruction set.
RISC is about making an architecture that is easy to implement by eliminating instructions that aren't needed for good performance. In doing this, designers can spend their gates on performance wins rather than on logic that can just as easily be reproduced in software. RISC is about putting gates where they count and not wasting them where they don't.
When you view RISC by it's actual principles, and not just by what the letters stand for, it's quite easy to see how SIMD units are entirely compatible. Of course, RISC as a differentiator has been obsolete for decades now and only exists as a point of argument for people who don't understand. RISC was an interesting topic...in 1988. You're 30 years behind.
Remember over a decade ago when people were claiming that Apple replacing PowerPC CPUs for Intel CPUs would never ever happen?
We still have people here on Slashdot and on Mac-related forums claiming that Apple will never ever replace Intel CPUs with their own ARM CPUs.
We now have supercomputers built with ARM CPUs. Given Apple's love of computing-power-to-watts ratios, and their need to control as many parts of their hardware as possible, it's only a matter of time. ARM-powered Macs are coming.
#DeleteFacebook
Nothing can run Crysis.
#DeleteFacebook
They likely chose 512 so that they didn't need to make all the necessary compiler improvements from scratch.
WHY not. Sparc is GPL'd and people still run OpenBSD on Sparc systems.
Sent from my ASR33 using ASCII
You will be armsimilated. All your Linux are belong to us.
The Russians have won. They have made the world a cesspool of distrust, greed, fear and hate.
You don't understand what "this guy" (David Patterson and Andrew Waterman) is writing. Their main complaint with regular SIMD is that it makes the instruction set grow quickly over time, as CPU performance is scaled up and SIMD units are made wider but old instructions still need to be supported for backward compatibility. They support vector instructions similar to ARM SVE, as those allow scaling up the performance by adding wide execution units without requiring the introduction of new instructions at the same time. As an additional benefit, those instructions can reduce the code size compared to regular SIMD. So by the standard of that article ARM SVE is not SIMD. The SIMD instructions they call harmful are only those older ones such as ARM Neon, SSE, AVX, AVX2, ... that use a fixed SIMD size.
And at the same time, their main complaint with those instruction sets is how they evolve over time when backward compatibility is required. If you are building a CPU for a specific purpose, let's say HPC or an embedded application, where you don't have to support old code, regular SIMD with only vector size support can be a very good choice and very RISC-like choice.
Jan
AVX can get wider too if it makes sense.
No, if you want to make AVX wider, then you would need to introduce a new instruction set. Intel did this several times. They started floating point SIMD with SSE which is 128-bit, then introduced the new AVX instruction set to support 256-bit wide SIMD and then AVX-512 to support 512-bit wide SIMD. If they want to scale up to 1024 or 2048-bit wide SIMD in the future than again, they will have to add new instructions and still need to support the old instructions for legacy software.
With traditional SIMD, your instruction set and the maximum width of your execution units are coupled. SVE removes this coupling. You can write SVE code now for a CPU with a 512-bit wide execution unit and would get a speedup later, without recompilation, if someone builds a CPU with a 2048-bit wide execution unit.
Jan
That was the glow-in-the-darek, go as fast as possible, not-parallel-enough Intel-like kludge. if you want a good SPARC, look at the T5. The T5 was small, cool, heavily parallel and utterly not what Oracle wanted (;-))
davecb@spamcop.net
RISC and SIMD address totally different issues. RISC is about the architecture of one CPU. SIMD is about how multiple CPUs work concurrently on various data sets