4 ms·
> 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?
by TillE 13y ago
> 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?
- haberman 13y agoThere is the x32 ABI -- not sure if this is in wide use or not: http://en.wikipedia.org/wiki/X32_ABI http://en.wikipedia.org/wiki/X32_ABI
- sltkr 13y agox32 is a great idea, but it was introduced too late (around 2012, I believe) and of course it is not widely used.
- RogerL 13y agoI'm pretty sure that means use int32_t instead of int64_t.
- cgh 13y agoCorrect. 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
- pbsd 13y agoYes, 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.
- cgh 13y ago"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.
- jfpoole 13y agoAArch64 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 http://www.arm.com/files/downloads/ARMv8_Architecture.pdf
- stephencanon 13y ago> 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.
- deleted 13y ago[deleted]
- eco 13y agoPointers 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.
- TillE 13y agoOh. That's sort of blindingly obvious, but fair enough.
- protopete 13y agoPointers 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.
- TorKlingberg 13y agoSo, 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?
- protopete 13y agoThe language is currently without raw pointers, suitable for an object system like Python/Ruby/JS.
- legulere 13y agoOn 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.