Following on from my last post about ExaGear, I’m going to run some benchmarks on my Raspberry Pi 3 to see how ExaGear performs against native applications.
I’ve opened up the case to do these benchmarks so that I can make sure that the Pi is operating at full capacity, rather than being limited by temperature and possible throttling.
Idle temperature of the Pi is approximately 35’C before running benchmarks as I have a USB fan cooling the Pi down so that I can continue running benchmarks as quickly as possible.
When I run the benchmarks, the temperature gets up to about 58’C.
The first run of
sysbench produced some interesting results with ExaGear being ahead by a couple of seconds.
Of course, I’ll do a few runs to get a better idea of how ExaGear performs against native.
I used the following command to run sysbench –
sysbench --num-threads=4 --test=cpu --cpu-max-prime=20000 --validate run
So after 4 runs, we have some results. As we can see from the spreadsheet above, ExaGear actually outperforms the benchmarks run natively. On average, Exagear finished almost 1.5 seconds quicker than native. As the ExaGear virtual machine is running a different kernel but on the same hardware, it’s interesting that the i686 benchmark performance was better than the ARMv7 results.
Next chance I get, I’ll be running some more benchmarks to see how ExaGear performs against Native.
Running ARMv7 Exagear on RPi 3’s ARMv8 SoC is as bad as running ARMv7 sysbench on an ARMv8 CPU. If you allow RPi 3 to run ARMv8 optimized code sysbench runs 15 times faster: https://github.com/bamarni/pi64/issues/4
In other words: A binary translation engine like Exagear might perform way better if compiled for the target platform (ARMv8) and not in compatibility mode (ARMv7). This way you simple waste CPU cycles for nothing.