Hacker News Reader

Comment by chasil | Hacker News Reader

It is far more impactful upon code density to compile 32-bit binaries, and eschew 64-bit.

Solaris was known to do precisely this for everything in /bin. I recently saw this in action on a copy of SmartOS, and I imagine that OpenIndiana does the same.

It's a shame that no major Linux distribution has openly performed this analysis for x86-64 and AArch64. ARM Thumb is also the smallest Busybox available for ARM 32-bit.

On the other hand, two copies of libc are essentially thrashing the instruction cache.

View on HN

Most common x86-64 instructions are 4 bytes already. The next most common instruction size used in many compiled 64-bit programs is 3 bytes, followed by 5 bytes.

I believe that AArch64 still uses 4-byte encodings for many instructions too, with a few that need 8 bytes.

Looking closer, I see that the difference between the latest busybox i686 and x86_64 versions is not large:

  busybox (i686)   2022-01-17 17:40  1.0M
  busybox (x86_64) 2022-01-17 18:53  1.1M

However, the savings on ARM Thumb appears to be larger, even for the various 32-bit binaries (v7m is Thumb, as I understand it):

  busybox-armv7m 2019-06-10 14:02  867K
  busybox-armv5l 2019-06-10 14:02  1.1M
  busybox-armv7l 2019-06-10 14:02  1.1M
  busybox-armv7r 2019-06-10 14:02  1.1M
  busybox-armv8l 2019-06-10 14:02  1.1M

Strange that Super-H is this large, as it inspired Thumb:

  busybox-sh4    2019-06-10 14:02  1.0M

https://busybox.net/downloads/binaries/

Thumb gives a lot of 2-byte instructions (like the RISC-V C extension), which makes sense for it to significantly reduce code size. ~20-30% is about the savings you would expect.

x86 has the huge disadvantage that it can't use 2-byte encodings for common instructions, since a lot of those are used by 16-bit and 8-bit instructions (which are almost completely unused today).

SH4 is relatively compact (16-bit instructions) but it isn't really compressed in the same way Thumb is. They shaved some corners to make things fit; e.g. there's only room for a 4 bit displacement in a load [R + disp] -> R type instruction. If you want to use an 8 bit displacement you have to use R0. This naturally leads to a lot of two-instruction sequences to calculate an offset into the stack, etc. which ends up practically more like classic MIPS in density.

Code density is not all about instruction length. It's also about instruction count. With shorter instructions you usually need to use more instructions to do the same thing (e.g. extra MOVs or stack spill etc).

The[/your?] article mentions two current concerns with code density, "Cache hit ratio," and "Instruction fetch bandwidth."

Does the footprint of Thumb (including total bytes, count of opcodes, speed, likely other things that I have not thought of) impact the conclusions in the paper?

Interesting that Thumb has been removed from AArch64, and that Intel never added anything like it.

My experience from Thumb was that it makes code slower. Probably because the CPU had to execute more insteuctions than in "ARM" mode.

Thumb was a thing for embedded systems with very limited RAM etc. It was not designed for optimal speed.

My guess is that ARM64 targeted higher end, and that severe memory constraints were no longer considered a big issue. ARM has its Cortex M4 (Thumb only microcontrollers) and the likes for those markets.

Reply on news.ycombinator.com