This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Memory footprint of 64-bit ARM compared to x86-64

I'm new to ARM.

My use case: Ubuntu LAMP

I need to know how big is the memory footprint for system running 64-bit ARM processor compared to x86-64.

(Benchmark is really appreciated)

  • There's a recent paper on this sort of thing

    Exploring the Limits of Code Density

    in it you'll see ARM 64-bit is the densest code of any straightforward RISC - just go to the last green bar in the graphs and you'll see arm64 beneath it. It is still slightly less dense than x86-64. It is denser than ARM 32-bit code but quite a bit less dense than Thumb-2 code - but possibly the main gain of 32 bit code is the smaller address sizes in the data. I think those were produced using gcc 4 and there's been a number of small improvements in gcc 5.

    Actual binaries for x86-64 tend to be often quite a bit larger but that is because they include all sorts of optional extras for ancient bits of legacy and changing instruction sets. If you're careful to compile them for the exact machine you're targeting the x86-64 should come down to about the same

    Added

    I see from their earlier paper they use icc for x86-64. This is better than gcc but I don't think it would make all that much difference for these tests.

    I think the code density of the 64 bit ARM ISA is quite impressive especially considering they said that they were not concerned about the density of code when designing it.

  • Technically x86 simply refers to a family of processors and the instruction set they all use. It doesn't actually say anything specific about data sizes. The term x86 started out as a 16-bit instruction set for 16-bit processors (the 8086 and 8088 processors), then was extended to a 32-bit instruction set for 32-bit processors (80386 and 80486), and now has been extended to a 64-bit instruction set for 64-bit processors. It used to be written as 80x86 to reflect the changing value in the middle of the chip model numbers, but somewhere along the line the 80 in the front was dropped, leaving just x86.