3 ms·

FWIW I recently tried this on https://www.oilshell.org https://www.oilshell.org, thinking the code would be faster due to better cache locality. There are many

by chubot 4y ago

FWIW I recently tried this on https://www.oilshell.org https://www.oilshell.org, thinking the code would be faster due to better cache locality. There are many pointer rich data structures and they should be packed much more tightly when pointers are 32 bit. It definitely saved memory, but it was slightly slower or the same speed. My guess is that 32-bit performance isn't prioritized on x86-64 by either compiler writers or chip designers, i.e. they optimize for the common case of 64 bit pointers. Definitely interested in other comments / opinions / data on this. I think if it actually sped programs up, you would see many more distros compiling packages for 32-bit. It does save memory, but somehow that's not big enough motivation. Probably because desktops/laptops have 8GB+ RAM these days (enough for most apps), and Linux systems with constrained memory are probably already 32-bit. And because real memory hogs like browsers probably want to address more than 4GB. Though to be honest I think a multi-process browser with a 4GB-per-origin limit sounds like a very good idea! Another issue is probably shared libs. Linux distros are pretty tightly coupled in this respect, and if core system programs like the compiler want to use 64-bit libc, etc. then it's economical for other programs to also be 64-bit as well. Otherwise the dependency management problem for shared libs becomes more annoying.

haimez 4y ago
> It definitely saved memory, but it was slightly slower or the same speed. My guess is that 32-bit performance isn't prioritized on x86-64 by either compiler writers or chip designers, i.e. they optimize for the common case of 64 bit pointers. That may be partially to blame, but depending on your implementation (was this x32 or actual compressed pointers?) the overhead of “decompressing” each pointer dereference may have been a significant factor. For null-safe languages like Java or JavaScript you already have null checks and may have GC barrier checks on most dereferences, so the extra costs are already expected- but adding a shift and/or constant add to each access is going to be a more noticeable cost compared to plain accesses in native code.
- chubot 4y ago
  This is dirt simple native C++ code compiled with -m32, with structs and pointers (which happens to be generated, but that doesn't matter here) I would expect that dereferencing a 32-bit pointer on x86-64 has zero overhead compared to dereferencing a 64-bit pointer (though I didn't test it). The only way I can see it being slower in the context of a real program is if the base address is an operand that has to be loaded from memory. But it shouldn't be because it's a 32-bit address space and it should be handled by the VMM, i.e. the base address is constant for the entire process.
  - bremac 4y ago
    -m32 doesn't target the x32 ABI though, it targets x86. Per the manual: > The -m32 option sets int, long, and pointer types to 32 bits, and generates code that runs on any i386 system. That restricts you to the smaller register set, removes all amd64 instructions, and uses the x86 ABI (on Linux, parameters are passed on the stack instead of in registers.) I suspect that this is why your program became slower, as opposed to using 32-bit pointers.
    - chubot 4y ago
      Hm so then how do you compile for x32 and have 32-bit pointers without the other restrictions? It sounds like x32 is poorly supported by Linux and x86 would be better supported.
      - bremac 4y ago
        I think that the answer here is "not easily". To use the x32 ABI, you would need: 1. Kernel support to be enabled in order to make x32 system calls. Checking /proc/config.gz on Arch Linux, my kernel does not appear to have it enabled. 2. An x32 toolchain to build against. For gcc and glibc, that would mean re-compiling as described here: https://sourceware.org/glibc/wiki/x32 https://sourceware.org/glibc/wiki/x32 3. All of the libraries you link with to be recompiled for the x32 ABI. x86 is definitely easier to build against since there's still legacy software using it, whereas almost nobody seems to use x32. However, over the long term I expect x86 compatibility will bit-rot too.
jdsully 4y ago
For x86 you have a lot less registers which makes it a bit of a wash. x32 is interesting because you get all the registers but keep the pointers small. Sadly it’s not well supported.

by chubot 4y ago

haimez 4y ago

> It definitely saved memory, but it was slightly slower or the same speed. My guess is that 32-bit performance isn't prioritized on x86-64 by either compiler writers or chip designers, i.e. they optimize for the common case of 64 bit pointers. That may be partially to blame, but depending on your implementation (was this x32 or actual compressed pointers?) the overhead of “decompressing” each pointer dereference may have been a significant factor. For null-safe languages like Java or JavaScript you already have null checks and may have GC barrier checks on most dereferences, so the extra costs are already expected- but adding a shift and/or constant add to each access is going to be a more noticeable cost compared to plain accesses in native code.

chubot 4y ago
This is dirt simple native C++ code compiled with -m32, with structs and pointers (which happens to be generated, but that doesn't matter here) I would expect that dereferencing a 32-bit pointer on x86-64 has zero overhead compared to dereferencing a 64-bit pointer (though I didn't test it). The only way I can see it being slower in the context of a real program is if the base address is an operand that has to be loaded from memory. But it shouldn't be because it's a 32-bit address space and it should be handled by the VMM, i.e. the base address is constant for the entire process.
- bremac 4y ago
  -m32 doesn't target the x32 ABI though, it targets x86. Per the manual: > The -m32 option sets int, long, and pointer types to 32 bits, and generates code that runs on any i386 system. That restricts you to the smaller register set, removes all amd64 instructions, and uses the x86 ABI (on Linux, parameters are passed on the stack instead of in registers.) I suspect that this is why your program became slower, as opposed to using 32-bit pointers.
  - chubot 4y ago
    Hm so then how do you compile for x32 and have 32-bit pointers without the other restrictions? It sounds like x32 is poorly supported by Linux and x86 would be better supported.
    - bremac 4y ago
      I think that the answer here is "not easily". To use the x32 ABI, you would need: 1. Kernel support to be enabled in order to make x32 system calls. Checking /proc/config.gz on Arch Linux, my kernel does not appear to have it enabled. 2. An x32 toolchain to build against. For gcc and glibc, that would mean re-compiling as described here: https://sourceware.org/glibc/wiki/x32 https://sourceware.org/glibc/wiki/x32 3. All of the libraries you link with to be recompiled for the x32 ABI. x86 is definitely easier to build against since there's still legacy software using it, whereas almost nobody seems to use x32. However, over the long term I expect x86 compatibility will bit-rot too.

jdsully 4y ago

For x86 you have a lot less registers which makes it a bit of a wash. x32 is interesting because you get all the registers but keep the pointers small. Sadly it’s not well supported.