Official ARM manycore/server thread

[retina]

Originally Posted by ldesnogu

And you know for sure that Apple itself won't make a laptop with a proper OS and an ARM chip? No one knows that for sure. And that's exactly why I phrased my very first comment in this thread the way I did (though I certainly was ambiguous when I talked about 'chips' rather than 'core' or 'CPU;).

This thread is about servers. Even if Apple do make a laptop, AND open the CPU specs for everyone, it wouldn't apply here. When I make my servers I don't make them from mobile Intel or AMD chips, I use server chips. And I need full documentation for everything else I can't make them.

[ldesnogu]

Well yes, but at least I did post some info about ARM servers. Conversation closed.

[ldesnogu]

TheNextPlatform:Arm’s Chances In Servers May Hinge On Success In HPC

[ldesnogu]

Another article from TheNextPlatform: Growing Up In An HPC World.

[ldesnogu]

Slides about upcoming Fujitsu chip with SVE: http://www.ssken.gr.jp/MAINSITE/even...PCF_shinjo.pdf


It's in Japanese but with enough English to get a few things. Impressive beast.

[ewmayer]

Originally Posted by ldesnogu

Slides about upcoming Fujitsu chip with SVE: http://www.ssken.gr.jp/MAINSITE/even...PCF_shinjo.pdf


It's in Japanese but with enough English to get a few things. Impressive beast.

If I read the english snips correctly, it uses 512-bit SIMD processed in 128-bit chunks by the read/write ports ... that would need a 512-bit ARMified version of my AVX-512 asm routines for Mlucas to exploit. Will any of these make their way in single-chip form into HPC workstations, or are they strictly for the supercomputer market?

At some point I'll surely need to do both 256-bit and 512-bit ARMv8 coding, but said SIMD widths would need to appear in volume in some consumer-market form (e.g. smartphones) to make the effort worthwhile.

[ldesnogu]

Originally Posted by ewmayer

If I read the english snips correctly, it uses 512-bit SIMD processed in 128-bit chunks by the read/write ports ...

I'm not sure where you got that 128-bit from. For the rest, yes, 2 x 512-bit wide FMA.

that would need a 512-bit ARMified version of my AVX-512 asm routines for Mlucas to exploit.

Yes, you'd need a dedicated path for using SVE, it's not the same instruction set as NEON.

Will any of these make their way in single-chip form into HPC workstations, or are they strictly for the supercomputer market?

I don't know for sure. But if it comes to low power devices it's likely it won't be very wide (both vector width, and number of units).

At some point I'll surely need to do both 256-bit and 512-bit ARMv8 coding, but said SIMD widths would need to appear in volume in some consumer-market form (e.g. smartphones) to make the effort worthwhile.

I think you missed the point of SVE: you don't need to care (too much) of the hardware vector length I think this document explains things nicely.

But that's perhaps me being naive (and underestimating your knowledge of SVE, sorry), and you still might care a lot due to FFT structure. At the very least, the instructions would be the same (contrary to AVX2 vs AVX-512).

I know you don't have a lot of free time, but if you ever want to start playing with SVE, you can pick a recent ARM cross-compiler and QEMU emulator (the SVE support in QEMU is validated).

[ewmayer]

Originally Posted by ldesnogu

I'm not sure where you got that 128-bit from. For the rest, yes, 2 x 512-bit wide FMA.

I mis-read slide #8, the one showing the read/write ports, as '128 bits/cycle', but in fact it reads '128 bytes/cycle'.

I think you missed the point of SVE: you don't need to care (too much) of the hardware vector length I think this document explains things nicely.

But that's perhaps me being naive (and underestimating your knowledge of SVE, sorry), and you still might care a lot due to FFT structure. At the very least, the instructions would be the same (contrary to AVX2 vs AVX-512).

Having data-width-independent instructions would be great, to be sure - but even so, there are 2 key areas where the width still matters:

1. Literal byte address offsets in asm instructions - this could surely be parameterized, say via a literal byte argument to the asm macros whose value is set at build time;

2. The FFT data are arranged in memory is a SIMD-width-dependent fashion, e.g. for 256-bit SIMD we use quartets of doubles, whereby 4 complex [re,im] double-pairs are stored as [0.re,1.re,2.re,3.re],[0.im,1.im,2.im,3.im]. In a typical FFT step we butterfly several such data segments from disjoint (wide-stide-separated) portions of the big data array, call them segments A,B,C,D,... . There are 2 points in each FFT-convolution step - one bracketing the dyadic-mul step beween the forward and inverse FFT, and another bracketing the round-and-carry step - where we need to transpose such data, e.g. in our 256-bit-double-quartets example, we need to take

[A0.re,A1.re,A2.re,A3.re]
[B0.re,B1.re,B2.re,B3.re]
[C0.re,C1.re,C2.re,C3.re]
[D0.re,D1.re,D2.re,D3.re]

and transpose those (and similarly for the im-parts) to

[A0.re,B0.re,C0.re,D0.re]
[A1.re,B1.re,C1.re,D1.re]
[A2.re,B2.re,C2.re,D2.re]
[A3.re,B3.re,C3.re,D3.re]

Such transposes unavoidably involve data-width-dependent shuffle/permute instructions. In an SVE-styke paradigm, the way to handle this would seem to break the transpose work out of the macros where it currently is combined with other non-transpose operations, thus minimizing the amount of asm code with data-width-dependent instructions.

I know you don't have a lot of free time, but if you ever want to start playing with SVE, you can pick a recent ARM cross-compiler and QEMU emulator (the SVE support in QEMU is validated).

That will be worth looking into once I complete work on the coming-soon Mlucas v19 code release, the one which adds support for PRP-testing with Gerbicz check.

[ldesnogu]

Thanks for the explanation!


I took a look at SVE support in gcc. Right now the intrinsics are not there, they're coming in version 10. I'm not sure if you need them.

[ldesnogu]

Fujitsu A64fx system (with SVE) tops Green 500 and ranks 159 on Top 500. It achieves 85% of the theoretical peak TFLOPS on LINPACK.

[ewmayer]

Originally Posted by ldesnogu

I took a look at SVE support in gcc. Right now the intrinsics are not there, they're coming in version 10. I'm not sure if you need them.

I don't use intrinsics myself, prefer to work 'close to the metal'. So the thing I need is inline-asm support from the compiler/assembler.