November-21st-2019, 02:48 PM
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
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:
64Bit:
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 ...
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)