VIM2 performance

We have been assessing the performance of the VIM2 with stress-ng and found that it actually performed much slower when compared to a Raspberry PI 3. Given the VIM2 is a 64bit octacore and the rPI is a 32bit quad core, we were quite surprised by these results. I am curious if you can advise as to what may be going on. The device seems particularly bad at floating point / matrix operations.

Raspberry PI 3
Architecture: armv7l
Byte Order: Little Endian
CPU(s): 4
On-line CPU(s) list: 0-3
Thread(s) per core: 1
Core(s) per socket: 4
Socket(s): 1
Model name: ARMv7 Processor rev 4 (v7l)
CPU max MHz: 1200.0000
CPU min MHz: 600.0000

Kernel
Linux TestPI 4.4.50-v7+ #970 SMP Mon Feb 20 19:18:29 GMT 2017 armv7l GNU/Linux

Khadas - VIM2
Architecture: aarch64
Byte Order: Little Endian
CPU(s): 8
On-line CPU(s) list: 0-7
Thread(s) per core: 1
Core(s) per socket: 4
Socket(s): 2
CPU max MHz: 1512.0000
CPU min MHz: 100.0000
Hypervisor vendor: (null)
Virtualization type: full

Kernel
Linux KhadasVIM2 4.9.40 #2 SMP PREEMPT Wed Sep 20 10:03:20 CST 2017 aarch64 aarch64 aarch64 GNU/Linux

@numbqq please follow up.

Did you have a heatsink and fan on it?

No, we are just running the stock board with no additional cooling.

This test is not performed correctly. Test source specifically optimized for the old 32 bit ARMv7. RPi3 has a chip ARMv8 (aarch64) , but you launch it the old (optimized for 32 bit) system with core ARMv7 (armhf). And VIM2 you launch the core ARMv8 (aarch64). So you deliberately put the VIM2 in a worse position. If you want to get correct test results, you must use the same system (all used utilities and the kernel needs to be collected using the same configurations and with the same copelatinae). RPI3 put on the same core and 64-bit aarch64 system as VIM2. Or use the VIM2 in 32 bit kernel and system ARMv7 (armhf).

IMHO
By the way, all these artificial tests are not of much interest, this is the toy for marketers, is to make clever conclusions and to show that their products are better. If you really want to compare devices, use real work on them. I have RPi3 and I compared them to real work with VIM\VIM2. Even weaker VIM1 (S905X) exceeds RPi3 in the real work. For real work it is important to have consistent speed ALL the used components (CPU, memory, I / o, etc.). What are the benefits that the processor can handle 10 of thousands of transactions, if the system I / o can only transmit a 1 one thousand.

3 Likes

To clarify, we included the rPI comparison to help quantify what we are experiencing with the VIM2, understanding fully that it is a very different architecture. This exercise is brought on by a real-world estimation of the VIM2 performance. We started prototyping our software on the rPI3 and ultimately plan on moving to a platform based on the S912. When we deployed our stack for verification on the VIM2 the performance was significantly worse than the rPI (both in base execution of the process right down to the initial act of compiling the code).

This post was not made to promote an off-balanced comparison which slams the Khadas board, as the VIM2 / S912 is of great interest to us. We are simply seeking answers as to what may cause such a huge discrepancy in compute performance when compared to our original prototype (almost a 10x difference in favor of the rPI).

i would stick a heatsink on it for starters - anything really intensive needs the cooling ive found

Thanks for the tip, we will definitely introduce proper cooling to rule it out. I could definitely see insufficient cooling as being a contributing factor to many issues over time, however these results are immediately apparent right after boot up.

When ive used high workloads i see that kicking in in less than a minute without proper cooling and getting bus errors etc when it carries on being loaded

I repeat. Architect have RPi3 and VIM2 General ARMv8 (aarch64). This architecture can perform both code for the ARMv7 (armhf) and ARMv8 (aarch64). You are running the tests on the kernel and world compiled for DIFFERENT architectures. If your software is compiled for ARMv7 (armhf), you need to use for VIM2 the kernel and system collected for the ARMv7 (armhf). Either you need to build your software (your program) with the use of the compiler options for ARMv8 (aarch64). In addition, something to use all the features of the VIM2, your software should be able to use 8 cores ( RPi3 used only 4 kernel).

1 Like

We are curious if there is an armhf Ubuntu build available for the VIM2 in the community before going through the process of creating our own from base?

Hi iwldev,

No armhf ubuntu image now.But if you want, you can build from Fenix.

Thanks.

We successfully built the OS yesterday using the Fenix script, however it does appear to have created a 64-bit build even though we specified a 32-bit environment. We also noticed that throughout the creation process, Fenix was only grabbing the 64-bit resources from source (toolchain, compiler,etc).

Thoughts?

FENIX_ENV
#KHADAS_BOARD=VIM2
#LINUX=4.9
#UBOOT=2015.01
#UBUNTU=16.04.2
#UBUNTU_ARCH=armhf
#INSTALL_TYPE=EMMC

Msg]version:0x2 crc:0x4fcf3ba2 size:863641780 bytes[823MB]
Pack image[images/khadas_vim2_emmc.img] OK
Done.

After installing with Burn Tool
Ubuntu 16.04.3 LTS (GNU/Linux 4.9.40 aarch64)
Linux Khadas 4.9.40 #1 SMP PREEMPT Tue Jan 23 20:33:29 UTC 2018 aarch64 aarch64 aarch64 GNU/Linux

Hi iwldev,

Yes Ubuntu rootfs is armhf but kernel is still 64 bit.

Thanks.

I’m not sure that this will solve the problem, but you can try the option Libreelec to S912. It uses armhf. You can try to run Libreelec (external media) to connect via SSH, copy your program into the system and try to start it. Pay attention, LE - uses Packed root system in the mode “read only”, so that would make changes to the settings, necessary to use special mechanisms (which are described in the documentation LE). Either to collect the required version of the LE (with the correct settings and additional software).

1 Like