Hacker News Reader

Hacker News

Comment by TillE | Hacker News Reader

Full thread

TillE

> Prefer 64-bit code and 32-bit data.

Wait, how is that possible? Like, you can have amd64 optimized code that uses 32-bit pointers?

View on HN

There is the x32 ABI -- not sure if this is in wide use or not: http://en.wikipedia.org/wiki/X32_ABI

x32 is a great idea, but it was introduced too late (around 2012, I believe) and of course it is not widely used.

I'm pretty sure that means use int32_t instead of int64_t.

Correct. I am curious why although I imagine it has to do with caching (fewer cache misses). Apparently he addresses it in the video but I haven't watched it yet.

On a meta-note, I'm really happy to see more highly technical submissions like this hitting and sticking on the front page.

EDIT: from the slides:

Prefer 32 bit ints to all other sizes

1. 64 bit may make some code slower [no additional explanation given]

2. 8, 16 bit computation use conversion to 32 bits and back

Yes, caching. 32 bit quantities are often sufficient, and take up less space in cache.

Additionally, code that handles 32-bit registers in x86_64 is often shorter than its 64-bit counterpart due to the lack of REX prefixes in instructions. This also reduces the instruction cache footprint. Some instructions like integer division and multiplication are also faster when handling 32-bit quantities, but this depends on the microarchitecture in question.

"Additionally, code that handles 32-bit registers in x86_64 is often shorter than its 64-bit counterpart due to the lack of REX prefixes in instructions."

Excellent point, thank you. I was only thinking about the data cache. Interestingly, I believe 64-bit ARM (AArch64) instructions are still only 32 bits long though I haven't confirmed via google. Maybe someone can correct me.

AArch64 instructions are still 32 bits long. These slides from the ARMv8 Technology Preview provide a great overview of the ARMv8 architecture:

http://www.arm.com/files/downloads/ARMv8_Architecture.pdf

> I believe 64-bit ARM (AArch64) instructions are still only 32 bits long

Correct, but I wouldn’t say “still”, since some “thumb” AArch32 instructions are 16b.

Pointers would be an exception, of course. As others wrote he's talking about general data. Just because 64-bit ints are faster on 64-bit processors than on 32-bit processors doesn't mean you should use them when a 32-bit int would suffice.

Oh. That's sort of blindingly obvious, but fair enough.

Pointers don't have to be the exception. I'm working on a programming language runtime where objects are stored as a 32-bit value, with 3/4 of the range representing an integer, and 1/4 of the range (30 bits) representing a pointer. Given the constraint that pointer objects are aligned to 8 bytes, the 30-bits multiplied by 8 results in an 8GB addressable memory space. Pages within that space can be allocated using mmap with MAP_FIXED flag. Smaller memory usage results in more things in cache, resulting in higher performance.

So, your pointers will not be able to address bytes individually? No char pointers, or is it 8 byte chars? Or is this a completely different language without raw pointers?

The language is currently without raw pointers, suitable for an object system like Python/Ruby/JS.

On x86-64 linux you can `mmap` with the `MAP_32BIT` flag which gives you memory in the 32 bit address space. As 32-bit writes to registers get implicitly zero-extended you can store and load those pointers in 32 bit without any performance drawbacks.

This all is a bit hackish. With the x32 abi you can simply have 32 bit pointers everywhere.

Reply on news.ycombinator.com