Fujitsu ARMs Itself For 1,000-PFLOPS HPC

“The Post-K machine is supposed to have 100 times more application performance than the K Supercomputer – which would make it a 1,000 PFLOPS beast – and is due to go live in 2020. The fastest known super in the world is China’s 125.4 PFLOPS Sunway TaihuLight machine, which would be crushed by the Post‑K if it lives up to its performance hype.
 
It would also make the world’s fastest known computer an ARM-powered system; there are no other ARM-powered supercomputers.”
 
See Fujitsu picks 64-bit ARM for Japan’s monster 1,000-PFLOPS super
Well, I suppose this vindicates my choice of ARM for computing here even with the ~20 billion scale factor…

About Robert Pogson

I am a retired teacher in Canada. I taught in the subject areas where I have worked for almost forty years: maths, physics, chemistry and computers. I love hunting, fishing, picking berries and mushrooms, too.
This entry was posted in technology and tagged , , , . Bookmark the permalink.

One Response to Fujitsu ARMs Itself For 1,000-PFLOPS HPC

  1. oiaohm says:

    Sparc64 vs Arm64 gets interesting.
    http://web.eece.maine.edu/~vweaver/papers/iccd09/ll_document.pdf
    Out of all the 64 bit risc class processors the Arm64 has the most compact instruction set. So swapping from space to arm64 makes sense to increase number of applications in ram.

    I know some will look at this and go hey the x86 instruction set is smaller. That example is not including the size difference x86 brings well allowing for all the instruction set variation but max compactness if you built targeting the exact x86 processor you have. When building binaries for distribution with the more uniform nature of the arm64 chips you end up smaller than x86 due to less cases of if cpu feature X exists do X do this else do Y. This difference comes clear when you start taking arm64 packages built for debian.
    https://packages.debian.org/stretch/libc6
    Package after package you will notice that arm64 has a smaller install size than even using i386 package in most cases and that is because the executable code has ended up more compact.

    This leads to a very interesting problem. amd64 vs arm64 system if both are using generic binaries the arm64 needs less ram to achieve same results. If you are a gentoo user or someone else who builds your binaries to exactly match your cpu the amd64 needs less ram than arm64 for same results. So to win against Arm64 intel/Amd really needs to somehow work out how to tidy up the x86 instruction set.

    The other thing to remember is sparc
    https://www.debian.org/ports/sparc/
    debian end support on in 2015.

    Yes sparc on average executables are larger than arm64 so to perform same tasks will need more ram and sparc OS support is dropping so swapping sparc to arm64 makes perfect sense.

    Google switching to powerv8 is kinda a what the think the libc eats up an extra 10megs of space on it own. Mind you power binaries do compress insanely well.

Leave a Reply