• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Experimenting with 64bit Raspbian OS on netPI
#1
Today I began experimenting with Raspbian OS on my netPI. Of interest was the 64Bit version specifically.

I programmed my micro SD card with the latest version Raspian OS, 2019-09-26: https://downloads.raspberrypi.org/raspbian_lite_latest first.

The only thing I did was then to insert the term

Code:
arm_64bit=1

in the config.txt file, pushed the card into the netPI (#REV2 with unseald SD card slot) SD card slot and booted netPI. A quick check on the console using

Code:
uname -a

showed "aarch64" ARM64 instruction set is active. WOW! That was easy.

After that I installed Docker and the Docker web UI portainer.io with

Code:
apt update
curl -sSL https://get.docker.com | sh
docker volume create portainer_data
docker run -d -p 9000:9000 -p 8000:8000 --name portainer --restart always -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer

Accessing the web UI at <netPI IP address>:9000 let me deal with Docker quite easily like I am use to on original netPI Hilscher OS.

I started two debian containers from Docker Hub. One 32Bit and one 64bit version.

   

In both containers I installed the tool sysbench (version https://github.com/akopytov/sysbench/arc....17.tar.gz to be exact) and check the CPU speed with

Code:
sysbench --test=cpu --cpu-max-prime=20000 --num-threads=4 run

Here are the results:

32Bit
Code:
CPU speed:
   events per second:    74.27

General statistics:
   total time:                          10.0493s
   total number of events:              747

Latency (ms):
        min:                                   53.10
        avg:                                   53.77
        max:                                   75.04
        95th percentile:                       53.85
        sum:                                40162.56

Threads fairness:
   events (avg/stddev):           186.7500/0.43
   execution time (avg/stddev):   10.0406/0.01

64Bit
Code:
CPU speed:
   events per second:   937.13

General statistics:
   total time:                          10.0037s
   total number of events:              9381

Latency (ms):
        min:                                    4.22
        avg:                                    4.26
        max:                                    9.81
        95th percentile:                        4.25
        sum:                                39993.05

Threads fairness:
   events (avg/stddev):           2345.2500/0.83
   execution time (avg/stddev):   9.9983/0.00

The counted events in 64Bit mode are 12.7 times higher. In turn this means the sysbench code sequence is executing around 12 times faster. 2nd WOW!! That is fast.

Of course I cannot exclude that this performance boost is somehow related to the sysbench tool itself that no relation to real applications. And also please keep in mind that sysbench was just calculating prime number during the tests. In no way this test represents and overall performance test that would cover also a memory benchmark and a disk benchmark (SD card). I found another thread that sets 64Bit and 32bit examinations in relation. The author came to 15 to 30% performance boost:https://www.cnx-software.com/2016/03/01/64-bit-arm-aarch64-instructions-boost-performance-by-15-to-30-compared-to-32-bit-arm-aarch32-instructions/
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#2
I continued experimenting with 64Bit compared to 32Bit.

I heard rumors that using 64Bit might cause higher memory consumption in terms of FLASH and RAM memory. But what is true in reality?

Following the ARM whitepaper here https://community.arm.com/developer/ip-p...arm-64-bit I learned that the ARM64 instruction set is always 32bit in lengths. So it is not like 64bit mode would double the code size.

But for data a value of the fundamental type "long" for example is now 64Bits wide, while a "long" under 32bit condition was 32bit. Types "char" and "short" remain at 8 respectively 16bits. So it is expected that code containing a lot of constants of type "long" will need for more space for code.

And indeed, the two containers arm32v7/debian and arm64v8/debian differ in their sizes. Here is what I got when I compared the image sizes under docker


Code:
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
arm64v8/debian      buster-20191014     b59066e92117        5 weeks ago         108MB
...
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
arm32v7/debian      buster-20191014     f67434cf7768        5 weeks ago         92.8MB

You see the 64bit image is about 16% larger.

But how about the RAM memory consumption ... I had two SD cards with the 32Bit and 64Bit setup running during my tests. I know just looking to plain containerized Debian doesn't count much since it is not a real application but at least it might show a trend.

So I used a console connecting to the containers and called the command "free" to look for the used overall memory including the OS itself and the container:

32Bit:
Code:
             total        used        free      shared  buff/cache   available
Mem:         948304      144676      112180        1052      691448      754180
Swap:        102396        8192       94204

64Bit:
Code:
             total        used        free      shared  buff/cache   available
Mem:         939024      145136      477276        6460      316612      733800
Swap:        102396           0      102396

If you now compare the "used" values you see there is not much difference the higher memory consumption of a 64Bit compilation is negligible.

To be continued ...
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)