Pine 64 benchmarks

[patrickhwood]

Here's my first set of bencharks for the Pine 64.

OS: Ubuntu 16.04, kernel 3.10.65
Compiler version: gcc 5.3.1
Compiler options: -static -O3 -mcpu=cortex-a53 -march=armv8-a -fomit-frame-pointer -funroll-loops
scaling_governor set to performance
CPU frequency: 1.152 GHz

Whetstone (double precision):

Code:

Loops: 1000000, Iterations: 1, Duration: 35 sec.

C Converted Double Precision Whetstones: 2857.1 MIPS

nbench 2.2.3:

Code:

TEST                : Iterations/sec.  : Old Index   : New Index
                    :                  : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT        :          533.93  :      13.69  :       4.50
STRING SORT         :          132.36  :      59.14  :       9.15
BITFIELD            :      2.2273e+08  :      38.21  :       7.98
FP EMULATION        :          144.41  :      69.29  :      15.99
FOURIER             :          8829.3  :      10.04  :       5.64
ASSIGNMENT          :          12.059  :      45.88  :      11.90
IDEA                :          2520.4  :      38.55  :      11.45
HUFFMAN             :          966.88  :      26.81  :       8.56
NEURAL NET          :          15.244  :      24.49  :      10.30
LU DECOMPOSITION    :          446.62  :      23.14  :      16.71
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX       : 37.365
FLOATING-POINT INDEX: 17.852
Baseline (MSDOS*)   : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==============================LINUX DATA BELOW===============================
CPU                 : 4 CPU
L2 Cache            : 
OS                  : Linux 3.10.65+
C compiler          : gcc version 5.3.1 20160225 (Ubuntu/Linaro 5.3.1-10ubuntu2) 
libc                : static
MEMORY INDEX        : 9.544
INTEGER INDEX       : 9.162
FLOATING-POINT INDEX: 9.901
Baseline (LINUX)    : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38

Here are the RPi 2 numbers for comparison:

OS: Raspbian 8, kernel 4.1.12
Compiler version: gcc 4.7.3
Compiler options: -static -O3 -mcpu=cortex-a8 -mtune=cortex-a8 -mfpu=neon -funroll-loops
scaling_governor set to performance
CPU frequency: 900 MHz

Code:

Loops: 300000, Iterations: 1, Duration: 25 sec.
C Converted Double Precision Whetstones: 1200.0 MIPS

Code:

TEST                : Iterations/sec.  : Old Index   : New Index
                   :                  : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT        :          428.62  :      10.99  :       3.61
STRING SORT         :          47.417  :      21.19  :       3.28
BITFIELD            :      1.3469e+08  :      23.10  :       4.83
FP EMULATION        :          59.695  :      28.64  :       6.61
FOURIER             :          3992.4  :       4.54  :       2.55
ASSIGNMENT          :          7.7852  :      29.62  :       7.68
IDEA                :            1655  :      25.31  :       7.52
HUFFMAN             :           687.7  :      19.07  :       6.09
NEURAL NET          :          6.3458  :      10.19  :       4.29
LU DECOMPOSITION    :          192.71  :       9.98  :       7.21
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX       : 21.614
FLOATING-POINT INDEX: 7.731
Baseline (MSDOS*)   : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==============================LINUX DATA BELOW===============================
CPU                 : 4 CPU ARMv7 Processor rev 5 (v7l)
L2 Cache            :
OS                  : Linux 4.1.12-hypriotos-v7+
C compiler          : arm-linux-gnueabihf-gcc
libc                : static
MEMORY INDEX        : 4.954
INTEGER INDEX       : 5.749
FLOATING-POINT INDEX: 4.288
Baseline (LINUX)    : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38

[nomadewolf]

Maybe you don't have one, but wouldn't the RPi3 be a more fair comparison?

[patrickhwood]

Maybe you don't have one, but wouldn't the RPi3 be a more fair comparison?

Right on both counts.

[janjwerner]

Michael @ phoronix.com just benchmarked several ARM boards. http://www.phoronix.com/scan.php?page=ar...berry-pi-3
I am running 'phoronix-test-suite benchmark 1603058-GA-RASPBERRY01' on my board right now, after it is done, I will re-run with the latest update from @longsleep.
From the first (unifinished test) the performance of Pine is slightly behind RPi 3 probably due to thermal throttling, slightly lower CPU frequency and the cpu governor.

[tllim]

Michael @ phoronix.com just benchmarked several ARM boards.  http://www.phoronix.com/scan.php?page=ar...berry-pi-3
I am running 'phoronix-test-suite benchmark 1603058-GA-RASPBERRY01' on my board right now, after it is done, I will re-run with the latest update from @longsleep.
From the first (unifinished test) the performance of Pine is slightly behind RPi 3 probably due to thermal throttling, slightly lower CPU frequency and the cpu governor.

I also curious on Pine A64 vs RPi 3 and looking forward on your benchmark result.

[patrickhwood]

Michael @ phoronix.com just benchmarked several ARM boards.  http://www.phoronix.com/scan.php?page=ar...berry-pi-3
I am running 'phoronix-test-suite benchmark 1603058-GA-RASPBERRY01' on my board right now, after it is done, I will re-run with the latest update from @longsleep.
From the first (unifinished test) the performance of Pine is slightly behind RPi 3 probably due to thermal throttling, slightly lower CPU frequency and the cpu governor.

These are all still 32 bit builds.  To see the real performance, we need 64 bit distros and benchmarks on both boards.

[janjwerner]

well I will run what is currently available. That should give us some insight. When 64bit builds are available I will redo the benchmarks. Another thing to test will be bsp vs mainline kernel. But lets gi one step at a time

[janjwerner]

Ok. first round check out "Pine64+ take 2"
http://openbenchmarking.org/result/16030...603058GA54

[longsleep]

Benchmark comparisons like this are not useful. You need to include thermal information (eg. heat sink, fan) temperature and thermal throttling details as well including environment temperature. Also you need to make sure that you did loose any cores during one benchmark and then run the next with only 2 or even 1 core (once they are off, they are not turned on again).

This is easy to do with RPi monitor which can easily be installed on the Pine64 with the script from @tkaiser: http://kaiser-edv.de/tmp/4U4tkD/install-...for-a64.sh

Share the graphs which capture the test runs.

Also i have some scripts to monitor on the command line at https://github.com/longsleep/build-pine6...rm-scripts and to turn disabled cores back on.

This are the thermal results running my optimized BSP on the Pine64 without heat sink at 23C room temperature while the pine lies flat on the table without enclosure.

idle

Code:

# pine64_health.sh
CPU freq       : 480.00 MHz
CPU count      : 4  
Governor       : interactive  
Core voltage   : 1.04 V
SOC Temp       : 38 C
Cooling state  : 0  
Cooling limit  : roomage:0,0,0,0,1152000,4,0,0

1 cpuburn-a8

Code:

# pine64_health.sh
CPU freq       : 1152.00 MHz
CPU count      : 4  
Governor       : interactive  
Core voltage   : 1.30 V
SOC Temp       : 56 C
Cooling state  : 0  
Cooling limit  : roomage:0,0,0,0,1152000,4,0,0  

2 cpuburn-a8

Code:

pine64_health.sh
CPU freq       : 1104.00 MHz
CPU count      : 4  
Governor       : interactive  
Core voltage   : 1.26 V
SOC Temp       : 74 C
Cooling state  : 1  
Cooling limit  : roomage:0,0,0,0,1152000,4,0,0

3 cpuburn-a8

Code:

pine64_health.sh
CPU freq       : 1008.00 MHz
CPU count      : 4  
Governor       : interactive  
Core voltage   : 1.20 V
SOC Temp       : 84 C
Cooling state  : 2  
Cooling limit  : roomage:0,0,0,0,1152000,4,0,0

4 cpuburn-a8

Code:

# pine64_health.sh
CPU freq       : 816.00 MHz
CPU count      : 4  
Governor       : interactive  
Core voltage   : 1.20 V
SOC Temp       : 91 C
Cooling state  : 3
Cooling limit  : roomage:0,0,0,0,1152000,4,0,0

This means, it runs stable at 816.00 MHz in cooling state 3 at around 90C with 4 cores burning with a8 optimized code. To add more load, run the cpuburn-53 code which utilized the full CPU capabilities and draws a lot more power / heat.

Also there is the undervoltage problem. If your Pine crashes/freezes it is not because of the heat - most likely you draw too much power and the USB cable / Power supply cannot provide it. Use better/shorter USB cable and another better power supply in such cases.

Cpuburn tools for arm: https://github.com/ssvb/cpuburn-arm

NOTE: Be careful with tuning the thermal details and running cpuburn - you can damage things!

[janjwerner]

OK, take two (err 4 )
http://openbenchmarking.org/result/16030...&obr_sor=y
http://imgur.com/LyEl9dz
and here with actually relevant data...
http://imgur.com/0ZAq3mO
benchmark started around 6.20 finished around 8.20. Ignore the first spike from the RPi Monitor.
There is a mysterious hole with cpu count dropped to 0, but vcore and soc temperature are stable so I think it's more of mis-handling the data rather than 4 cpu's giving up.
Power supply: AC/DC CONVERTER, 11W, 5V, 2.2A;  from Digikey ( sadly not available atm). I guess one could try this one: http://www.newark.com/stontronics/t5875d...dp/77Y6535
or
http://www.amazon.com/CanaKit-Raspberry-...B00MARDJZ4
Heatsink: http://www.amazon.com/gp/product/B00XJ25R3G (again I had one laying around from my Pi)