4 ms·

Many workloads do not require more than 4GB addressable RAM per process. Linux offered a 32-bit user space with 64-bit instruction set: https://en.m.wikipedia.

Many workloads do not require more than 4GB addressable RAM per process. Linux offered a 32-bit user space with 64-bit instruction set: https://en.m.wikipedia.org/wiki/X32_ABI https://en.m.wikipedia.org/wiki/X32_ABI As effectively many Python workloads are usually object oriented business logic and objects are mostly pointers, setting up x32 user space "halved" the memory usage. It also made execution performance faster because of better CPU cache utilisation. Sadly, x32 was "very custom" and very hard to support. Last I heard x32 is being phased out from Linux kernel.

miohtama 7y ago
Looks like this little gem was in the Wikipedia article > The best results during testing were with the 181.mcf SPEC CPU 2000 benchmark, in which the x32 ABI version was 40% faster than the x86-64 version.
chrisseaton 7y ago
Another option is to use the standard 64 bit ABI, but store object pointers compressed into 32 bits when on the heap. This lets you address perhaps 32 GB in a 32 bit value.
- srean 7y ago
  Could you elaborate more on how the 'compress' part works. Quite curious. I can imagine working with a base pointer and 32 bit offsets.
  - miohtama 7y ago
    Also curious about this. Does 64-bit instruction set provide some segments or functionality form this? How about "native" pointers coming from glib and such? If there has to be base + offset translation on every pointer access it is way too slow. I would also assume JavaScript VMs in browsers would be already utilising this, as web page workloads are not gigabytes (hopefully).
    - deleted 7y ago
      [deleted]
    - chrisseaton 7y ago
      > If there has to be base + offset translation on every pointer access it is way too slow. It does do this, but it's not too slow - the overhead of the translation is lower than the benefit of reduced memory transfer, increased cache space, etc. Obviously - otherwise people wouldn't be doing it.
    - jerven 7y ago
      I don't think the current V8 release has this build in yet. This something the common JVMs have been doing this since at least 2006.
    - cesarb 7y ago
      > If there has to be base + offset translation on every pointer access it is way too slow. The memory access instructions in the x86 ISAs can do base + offset in a single instruction.
    - kccqzy 7y ago
      > If there has to be base + offset translation on every pointer access it is way too slow. It's time to update your intuition: memory access is usually slow, much slower than simple arithmetic.
  - chrisseaton 7y ago
    Do you need to address every byte in your memory? If all your Python objects are at least two words in size, or more, then no, you only need to address every 16 bytes or so. So shift your whole pointer right a bit and you can address more than 4 GB of objects in a 32 bit pointer.
  - Erwin 7y ago
    Java for example, can use "compressed OOPs" -- ordinary object pointers. This is a 32-bit stored pointer but shifted, as pointers to objects always point to something on multiple of 8 bytes. So the shifted address is stored, but then shifted left before being dereferenced, allowing addressing of 32GB memory with 32-bit references. I read some longer article about the evolution and options for memory addressing in JVM, if only I could find it... but here's another one: https://wiki.openjdk.java.net/display/HotSpot/CompressedOops https://wiki.openjdk.java.net/display/HotSpot/CompressedOops There are variations on this method that can be applied to other memory management pools. For example, let's say are allocating many objects for processing, need them only within a certain span of time and have to free all of them when it's over. Well, rather than individually tracking allocations you can allow a single perhaps growing memory area, store the start offset somewhere and reference them with a shorter reference relative to that area.
winter_blue 7y ago
Wow, this is really amazing. I've always felt like 64-bit pointers were a huge waste of memory, since many small tools need well below 4 GB. Cache is always going be relatively small (unless semiconductor/transistor fabrication costs drop dramatically), and smaller pointers result in better cache usage, and consequently fewer cache misses. > Sadly, x32 was "very custom" and very hard to support. Last I heard x32 is being phased out from Linux kernel. This is really sad to hear. Do you happen to know of any kernel discussion threads on this besides this one[1]? (I'd love to chime in, in support of the X32 ABI.) I'm a little surprised honesty, as Linus has mentioned multiple times how important it is to him that the user-facing ABI remain stable. [1] https://lkml.org/lkml/2018/12/10/1145 https://lkml.org/lkml/2018/12/10/1145
snek 7y ago
Interestingly, V8 (the JS engine) is actively finishing up its own implementation of 32 bit pointer compression. https://bugs.chromium.org/p/v8/issues/detail?id=7703 https://bugs.chromium.org/p/v8/issues/detail?id=7703

miohtama 7y ago

Looks like this little gem was in the Wikipedia article > The best results during testing were with the 181.mcf SPEC CPU 2000 benchmark, in which the x32 ABI version was 40% faster than the x86-64 version.

chrisseaton 7y ago

Another option is to use the standard 64 bit ABI, but store object pointers compressed into 32 bits when on the heap. This lets you address perhaps 32 GB in a 32 bit value.

srean 7y ago
Could you elaborate more on how the 'compress' part works. Quite curious. I can imagine working with a base pointer and 32 bit offsets.
- miohtama 7y ago
  Also curious about this. Does 64-bit instruction set provide some segments or functionality form this? How about "native" pointers coming from glib and such? If there has to be base + offset translation on every pointer access it is way too slow. I would also assume JavaScript VMs in browsers would be already utilising this, as web page workloads are not gigabytes (hopefully).
  - deleted 7y ago
    [deleted]
  - chrisseaton 7y ago
    > If there has to be base + offset translation on every pointer access it is way too slow. It does do this, but it's not too slow - the overhead of the translation is lower than the benefit of reduced memory transfer, increased cache space, etc. Obviously - otherwise people wouldn't be doing it.
  - jerven 7y ago
    I don't think the current V8 release has this build in yet. This something the common JVMs have been doing this since at least 2006.
  - cesarb 7y ago
    > If there has to be base + offset translation on every pointer access it is way too slow. The memory access instructions in the x86 ISAs can do base + offset in a single instruction.
  - kccqzy 7y ago
    > If there has to be base + offset translation on every pointer access it is way too slow. It's time to update your intuition: memory access is usually slow, much slower than simple arithmetic.
- chrisseaton 7y ago
  Do you need to address every byte in your memory? If all your Python objects are at least two words in size, or more, then no, you only need to address every 16 bytes or so. So shift your whole pointer right a bit and you can address more than 4 GB of objects in a 32 bit pointer.
- Erwin 7y ago
  Java for example, can use "compressed OOPs" -- ordinary object pointers. This is a 32-bit stored pointer but shifted, as pointers to objects always point to something on multiple of 8 bytes. So the shifted address is stored, but then shifted left before being dereferenced, allowing addressing of 32GB memory with 32-bit references. I read some longer article about the evolution and options for memory addressing in JVM, if only I could find it... but here's another one: https://wiki.openjdk.java.net/display/HotSpot/CompressedOops https://wiki.openjdk.java.net/display/HotSpot/CompressedOops There are variations on this method that can be applied to other memory management pools. For example, let's say are allocating many objects for processing, need them only within a certain span of time and have to free all of them when it's over. Well, rather than individually tracking allocations you can allow a single perhaps growing memory area, store the start offset somewhere and reference them with a shorter reference relative to that area.

winter_blue 7y ago

Wow, this is really amazing. I've always felt like 64-bit pointers were a huge waste of memory, since many small tools need well below 4 GB. Cache is always going be relatively small (unless semiconductor/transistor fabrication costs drop dramatically), and smaller pointers result in better cache usage, and consequently fewer cache misses. > Sadly, x32 was "very custom" and very hard to support. Last I heard x32 is being phased out from Linux kernel. This is really sad to hear. Do you happen to know of any kernel discussion threads on this besides this one[1]? (I'd love to chime in, in support of the X32 ABI.) I'm a little surprised honesty, as Linus has mentioned multiple times how important it is to him that the user-facing ABI remain stable. [1] https://lkml.org/lkml/2018/12/10/1145 https://lkml.org/lkml/2018/12/10/1145

snek 7y ago

Interestingly, V8 (the JS engine) is actively finishing up its own implementation of 32 bit pointer compression. https://bugs.chromium.org/p/v8/issues/detail?id=7703 https://bugs.chromium.org/p/v8/issues/detail?id=7703