Next-gen Odroid announcement

[ldesnogu]

Originally Posted by nomead

In the same directory as the temp file, see the type file. It should tell what the corresponding temperature reading is for.

Very useful, thanks!

Originally Posted by ewmayer

Laurent, thanks for the data. Based on your timings, it seems the OS is doing a decent job of load-balancing even in the affinity-fail cases, though some of the large run-to-run timing variability you observe may be due to that.

That's my hypothesis too. I would also add that given that they are close to the end of the run it's possible threads are moved to less powerful cores to reduce temperature; the other possible explanation is that there's a hardware frequency throttler to prevent the chip from getting damaged.

Oh, would you be so kind as to post a copy of your /proc/cpuinfo file? Thanks.

Here you go:

processor    : 0
BogoMIPS    : 38.40
Features    : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp
CPU implementer    : 0x51
CPU architecture: 8
CPU variant    : 0x7
CPU part    : 0x803
CPU revision    : 12

processor    : 1
BogoMIPS    : 38.40
Features    : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp
CPU implementer    : 0x51
CPU architecture: 8
CPU variant    : 0x7
CPU part    : 0x803
CPU revision    : 12

processor    : 2
BogoMIPS    : 38.40
Features    : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp
CPU implementer    : 0x51
CPU architecture: 8
CPU variant    : 0x7
CPU part    : 0x803
CPU revision    : 12

processor    : 3
BogoMIPS    : 38.40
Features    : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp
CPU implementer    : 0x51
CPU architecture: 8
CPU variant    : 0x7
CPU part    : 0x803
CPU revision    : 12

processor    : 4
BogoMIPS    : 38.40
Features    : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp
CPU implementer    : 0x51
CPU architecture: 8
CPU variant    : 0x6
CPU part    : 0x802
CPU revision    : 13

processor    : 5
BogoMIPS    : 38.40
Features    : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp
CPU implementer    : 0x51
CPU architecture: 8
CPU variant    : 0x6
CPU part    : 0x802
CPU revision    : 13

processor    : 6
BogoMIPS    : 38.40
Features    : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp
CPU implementer    : 0x51
CPU architecture: 8
CPU variant    : 0x6
CPU part    : 0x802
CPU revision    : 13

processor    : 7
BogoMIPS    : 38.40
Features    : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp
CPU implementer    : 0x51
CPU architecture: 8
CPU variant    : 0x6
CPU part    : 0x802
CPU revision    : 13

The 0:3 CPUs are the A53 derivatives and the 4:7 are the A75 derivatives.

[paulunderwood]

121 days on the a73 (N2):

M91410271 is not prime. Res64: 415636F42C8F81__. Program: E18.0. Final residue shift count = 48867609

I am doing another WR LL test followed by a DC test.

[ewmayer]

Thanks for the cycles! That's about what I get @5120K (~120 ms/iter) on the 4-core Snapdragon CPU of my Galaxy S7s - but I need to put them into good airflow (USB fan) to get the timings down to that. Are you putting your N2 into airflow or just passively using the big attached heatsink?

[paulunderwood]

Originally Posted by ewmayer

Thanks for the cycles! That's about what I get @5120K (~120 ms/iter) on the 4-core Snapdragon CPU of my Galaxy S7s - but I need to put them into good airflow (USB fan) to get the timings down to that. Are you putting your N2 into airflow or just passively using the big attached heatsink?

I have a 80mm USB fan directly underneath the heatsink base. It adds significantly to the wattage of the system. This N2 is my desktop machine. During the forthcoming summer months I plan to shutdown all X64 machines and just run the N2 and rpi 3B+ -- any extra heat here will not be welcome. During the depths of winter I will run some 140 X64 cores to keep me warm.

[paulunderwood]

I am impressed by how fast mlucas is on the A73 chip of my Odroid N2 compared to 8 cores of single chip AMD 6176 (Opteron 12 core at 2.3 GHz) running mprime:

mprime on 8 cores of AMD Opteron: ms/iter: 47.678
mlucas on 4 cores of ARM a73: 119.6611 msec/iter

(I could probably get more throughput on the Opteron, but I am running down tasks for it for the upcoming summer months.)

[ewmayer]

Originally Posted by paulunderwood

I am impressed by how fast mlucas is on the A73 chip of my Odroid N2 compared to 8 cores of single chip AMD 6176 (Opteron 12 core at 2.3 GHz) running mprime:

mprime on 8 cores of AMD Opteron: ms/iter: 47.678
mlucas on 4 cores of ARM a73: 119.6611 msec/iter

(I could probably get more throughput on the Opteron, but I am running down tasks for it for the upcoming summer months.)

What FFT length is that at? That's actually a pretty decent apples-to-apples comparison, given the 128-bitness of both those CPU's SIMD units. Also note that w.r.to ARM, much depends on what kinds of hardware resources support that SIMD - I've never gotten a definitive answer from anyone on this, but based on scalar-FFT vs 128-bit SIMD build timings on ARM, where the former runs ~2/3 as fast as latter (compared to ~1/3 for Mlucas built both ways on my Core2Duo), I'm reaonably certain that on most ARM implementations, the SIMD uses the same underlying functional units (adders, multipliers, etc) as the non-SIMD. The SIMD thus gets its speedup not from more transistors dedicated to it as is the case on x86, but from the combination of a leaner instruction stream (fewer instructions needed to process the same data volume) and better register usage.

My surmise makes sense also in the context of ARM aiming for the performance-per-Watt-hour market segment - you want as little silicon as possible underpinning the instruction set, so non-SIMD and SIMD instructions sharing the same hardware makes sense. Said sharing is facilitated by not having a crufty legacy non-IEEE register data format such as x86 has with its 80-bit register-double-floats.

What's really needed on the ARM front is wider SIMD, cheap manycore, and perhaps some higher-end implementations which do provide dedicated silicon to feed that SIMD.

[paulunderwood]

Originally Posted by ewmayer

What FFT length is that at?

AMD: [Work thread Mar 11 14:08] Resuming Gerbicz error-checking PRP test of M103xxxxxx using AMD K10 type-2 FFT length 5600K, Pass1=896, Pass2=6400, clm=4, 8 threads

ARM: M103xxxxxx: using FFT length 5632K = 5767168 8-byte floats, initial residue shift count = 61642481
this gives an average 18.027884223244406 bits per digit
The test will be done in form of a 3-PRP test.
Using complex FFT radices 352 16 16 32

[ldesnogu]

Originally Posted by ewmayer

What FFT length is that at? That's actually a pretty decent apples-to-apples comparison, given the 128-bitness of both those CPU's SIMD units. Also note that w.r.to ARM, much depends on what kinds of hardware resources support that SIMD - I've never gotten a definitive answer from anyone on this, but based on scalar-FFT vs 128-bit SIMD build timings on ARM, where the former runs ~2/3 as fast as latter (compared to ~1/3 for Mlucas built both ways on my Core2Duo), I'm reaonably certain that on most ARM implementations, the SIMD uses the same underlying functional units (adders, multipliers, etc) as the non-SIMD. The SIMD thus gets its speedup not from more transistors dedicated to it as is the case on x86, but from the combination of a leaner instruction stream (fewer instructions needed to process the same data volume) and better register usage.

My surmise makes sense also in the context of ARM aiming for the performance-per-Watt-hour market segment - you want as little silicon as possible underpinning the instruction set, so non-SIMD and SIMD instructions sharing the same hardware makes sense. Said sharing is facilitated by not having a crufty legacy non-IEEE register data format such as x86 has with its 80-bit register-double-floats.

What's really needed on the ARM front is wider SIMD, cheap manycore, and perhaps some higher-end implementations which do provide dedicated silicon to feed that SIMD.

You can find Software Optimization guides here: https://developer.arm.com/docs

Nothing for A73 it seems. But there is A75 A76 A77 N1.

For A73 there is this: https://www.anandtech.com/show/10347...mis-unveiled/2

[ewmayer]

Originally Posted by ldesnogu

You can find Software Optimization guides here: https://developer.arm.com/docs

Nothing for A73 it seems. But there is A75 A76 A77 N1.

For A73 there is this: https://www.anandtech.com/show/10347...mis-unveiled/2

That Anandtech article addresses the how-many-underlying-functional-units question:

We find two simple ALUs capable of basic operations such as additions and shifting. Integer multiplication, division and multiply-accumulate operations are handled by a dedicated multi-cycle integer pipeline. Floating point as well as ASIMD and NEON operations are handled by two pipelines, some of the capabilities we’ll go into detail later on. We find a single branch monitor and two dedicated Load and Store AGUs.

[paulunderwood]

My N2 just finished its first wave front PRP test successfully modulo a double check No GEC errors were encountered.

[ET_]

Originally Posted by paulunderwood

My N2 just finished its first wave front PRP test successfully modulo a double check No GEC errors were encountered.

I just noticed the new N2+ has been announced.
BTW, how do you deal with the big-little 6-cores architecture? You probably already told us, but I lost the pointer, and if you have it at hand...