2

From the range of OSs available for Raspberry Pi, I would like to know whether the distro impacts the performance of the OS in pure terminal mode. I plan to run computationally power consuming algorithms with it and hence I would like to get the best out of its performance.

Specifically, I am interested in Raspbian, Ubuntu MATE and ArchLinux. How does the performance compare when there is not GUI related process running at the backround? Suppose if I were to disable the startx to boot in text mode, will there be a difference in the speed between these distros?

I would prefer Raspbian or Ubuntu MATE as it already has its WiFi and Bluetooth readily configured (I need them both), but was wondering if Arch can be any faster.

Ébe Isaac
  • 1,011
  • 2
  • 9
  • 12

3 Answers3

3

I would like to know whether the distro impacts the performance of the OS in pure terminal mode. I plan to run computationally power consuming algorithms with it and hence I would like to get the best out of its performance...

It depends on the computation and the OS, and less on the terminal. The RPI-3 is ARMv8/Aarch64. ARMv8 is 64-bit, so it can be more efficient than earlier models of the Raspberry Pi.

ARMv8/Aarch64 also has two (maybe more) useful instructions: pmull and pmull2. They perform 64x64 → 128-bit carryless multiplies. The multiplier can be used in a larger multiplier that improves speed in some context by 30%. Additional instructions include hardware acceleration for CRC, AES, SHA1 and SHA2.

The OS image provided by the Raspberry project does not utilize or expose the ARMv8 instructions; and the toolchain is not capable of compiling programs which take advantage of the instructions (even though Aarch32 executions environments on Aarch64 are completely valid). Also see Enable crc32 for armv7? on the GCC help mailing list.

Raspbian, Ubuntu MATE and ArchLinux...

I think you should make ARMv8/AArch64 a priority in your quest. Unfortunately, I don't believe you will find a 64-bit OS from Ubuntu or ArchLinux. My apologies if its bike shedding.

The CentOS ARM folks are getting ready to investigate the feasibility of a 64-bit OS image for the device. Also see Raspberry Pi 3 and Aarch64 image? on the ARM-dev mailing list.

You can see some of the cpu features by inspecting /proc/cpuinfo. Notice its missing:

$ cat /proc/cpuinfo
processor   : 0
model name  : ARMv7 Processor rev 4 (v7l)
BogoMIPS    : 38.40
Features    : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part    : 0xd03
CPU revision    : 4
...

Hardware    : BCM2709
Revision    : a22082
Serial      : 00000000e7ffc20d

Notice its missing flags like pmull and pmull2. Surprisingly, it includes crc32 (because its an ARMv8 extension).

I know the Broadcom SoC can consume the instructions because I wrote a program that tested the instructions. The program simply emitted the byte codes for the instructions, and the compiler could not stop me from using them :)

If interested, here's what it would look like. If you compile it with -march=armv7-a -mfpu=neon and the run it, then you will notice it does not die with an illegal instruction and it returns 0 as expected.

$ cat ../test.cc
#include <arm_neon.h>
int main(int argc, char* argv[])
{
  __asm__ __volatile__
  (
   #ifndef __aarch64__
     ".code 32"
   #endif

   // PMULL
   ".byte 0x0e, 0xe1, 0xe0, 0x00;\n"
   // PMULL2
   ".byte 0x4e, 0xe1, 0xe0, 0x00;\n"
   ...

  : : : "cc", "d0", "d1", "d2", "q0", "q1", "q2"
 );

  return 0;
}
Community
  • 1
2

I don't have a thorough answer as I have not done any benchmarking or deep investigation of such, but the only thing that could be significant here is the difference between something compiled for ARMv6 (e.g., Raspbian), something compiled for ARMv7 (various distros targeting the 2/3 including Ubuntu variants), and something targeting 64-bit ARMv8 (Pi 3 only; there is nothing pi specific here, but there are distros you could adapt to it).

I run an ARMv7 distro on the 2/3 and TBH I do not think that amounts to much if any difference performance wise. The version of ARMv6 implemented on the single core models, for which Raspbian is compiled, is actually very close to v7. Further, the fact that the Raspberry Pi Foundation did their benchmarks on the 2 and 3 using Raspbian implies that they did not see a huge advantage in using anything else (I do not have a direct reference for that but it is implicit in the material on their site).

A quick search regarding "aarch64" distro benchmarks on the Pi 3 at first seems to offer a modest advantage, although if you look closely at that page you'll notice the tests weren't done on a Pi 3, they were done on a Cortex based Juno board -- something to watch out for if you do your own research.

At this point, if someone had demonstrated aarch64 made much difference on the Pi 3, I think that information would be easy to find, so the silence implies it does not.

How does the performance compare when there is not GUI related process running at the background?

Running something inside a GUI won't make any real difference performance wise unless the additional memory consumed becomes significant. Ideally, on the pi you probably want at least 50-100 MB free for the page cache, which does generally speed performance. If you are not getting that, you want to try and free some up, whether it is from a GUI or something else. Beware that many tools include (or distinguish) the page cache in their reporting of memory use, so if at first it appears full, check and see if that is the case. If it includes the cache and the system has been in use for a while, it should be full.

Likewise, if there are other things active and contending for CPU time that are part of the GUI, this will have an impact. However, this is equally possible without a GUI. In my experience the only significant culprits here are (ironically) eye candy system monitors, which on a pi may use as much as 5-10% of a core depending how frequently they update.

You can use tools such as top or htop to check for this kind of thing, GUI or not. Since they're monitors, they may end up appearing frequently near the top of their own list, but you only need them for evaluation.

goldilocks
  • 60,325
  • 17
  • 117
  • 234
0

If your application benefits from the extra instructions available in the Armv8 instruction set, then you could consider Gentoo and build your own. I looked at the Gentoo Raspberry Pi guide and it looks like a doable solution. The Gentoo community has good and knowledgable support. If you're setting up multiple Pis, then it might not be a big overhead. The most hassle could be the distcc setup for compiling everyt

NTwoO
  • 1