4 ms·

Not just more power-efficient, but also a little more memory efficient because pointers are only half as big and so don't take up as much space in the cache. Lo

Not just more power-efficient, but also a little more memory efficient because pointers are only half as big and so don't take up as much space in the cache. Lower-bit chips are also smaller (which could translate into faster clock and/or more functional units per superscaler core and/or more cores per die). Part of the problem with these discussion is that often when people say "64-bit" vs "32-bit" they are also considering all the new useful instructions that were added to the new instruction set generation. But a true "apples-to-apples" comparison between "32-bit" and "64-bit" should be using almost identical whose only difference is the datapath and pointer size. I feel that the programs and games I run shouldn't really need more than 4GB memory anyway, and the occasion instance that the extra precision of 64-bit math is useful could be handled by emulating the 64-bit math with the compiler adding a couple extra 32-bit instructions.

yjftsjthsd-h 1y ago
I wish x32 had taken off; better performance and lower memory use. https://wiki.debian.org/X32Port https://wiki.debian.org/X32Port
- NoGravitas 1y ago
  I have a netbook that would really benefit from that. It's a 64-bit Atom processor. Currently I'm running a 32-bit kernel and userspace, but it looks like the way forward is going to be 64-bit kernel and 32-bit userspace.
  - lproven 1y ago
    > 64-bit kernel and 32-bit userspace That's what the Raspberry Pi Desktop did. It's the Pi project's x86 OS, a drastically cut-down Debian with LXDE. It was pretty much the smallest full-desktop distro I've seen. (Excluding specialist things with window managers like antiX or TinyCore.) Sadly never made it off Bookworm. I wish they'd update it, or someone took over maintenance.
kbolino 1y ago
Applications don't get 4GB with a 32-bit address space. The practical split between application and kernel was usually 1-3 or 2-2 with 3-1 being experimental and mooted with the switch to 64-bit. Nowadays with VRAM being almost as large as main RAM, you need the larger address space just to map a useful chunk of it in. When you factor in memory fragmentation, you really only had a solid 0.75-1.5GB of space that could be kept continuously in use. That was starting to become a problem even when 32-bit was the only practical option. A lot of games saw a benefit to just having the larger address space, such that they ran better in 64-bit with only 4GB of RAM despite the fatter 64-bit pointers.
- vlovich123 1y ago
  I believe that's an accident of the evolutionary path chosen with syscalls. If we'd instead gone with a ring buffer approach to make requests, then you'd never need to partition the memory address space; the kernel has its memory and userspace has its and you don't need the situation where the kernel is always mapped.
  - kbolino 1y ago
    Hmm. I don't understand how that would work. I think it would be possible for e.g. microkernels to greatly reduce the size of the reservation (though not to eliminate it entirely). However, I can't imagine how you would handle the privilege escalation issue without having at least some system code in the application's virtual address space that's not modifiable by the application.
    - vlovich123 1y ago
      I'm not sure how privilege escalation would be an issue since you'd never escalate privilege in the first place (I'm assuming you're talking about CPU ring privileges and not OS privileges). You'd just enqueue into the shared kernel/user space ring buffer your operations and the kernel would pick them up on its side, but you'd never jump between rings. Such a design may require at least one processor dedicated to running the kernel at all times, so it might not work on a single processor architecture. However, single processor architectures might be supportable by having the "kernel process" go to sleep by arming a timer and the timer interrupt is the only one that's specially mapped so it can modify the page table to resume the kernel (for handling all the ring buffers + scheduling). As you note, there's some reserved address space but it's a trivial amount just to be able to resume running the kernel. I don't think it has anything to do with monolithic vs microkernels.

yjftsjthsd-h 1y ago

I wish x32 had taken off; better performance and lower memory use. https://wiki.debian.org/X32Port https://wiki.debian.org/X32Port

NoGravitas 1y ago
I have a netbook that would really benefit from that. It's a 64-bit Atom processor. Currently I'm running a 32-bit kernel and userspace, but it looks like the way forward is going to be 64-bit kernel and 32-bit userspace.
- lproven 1y ago
  > 64-bit kernel and 32-bit userspace That's what the Raspberry Pi Desktop did. It's the Pi project's x86 OS, a drastically cut-down Debian with LXDE. It was pretty much the smallest full-desktop distro I've seen. (Excluding specialist things with window managers like antiX or TinyCore.) Sadly never made it off Bookworm. I wish they'd update it, or someone took over maintenance.

kbolino 1y ago

Applications don't get 4GB with a 32-bit address space. The practical split between application and kernel was usually 1-3 or 2-2 with 3-1 being experimental and mooted with the switch to 64-bit. Nowadays with VRAM being almost as large as main RAM, you need the larger address space just to map a useful chunk of it in. When you factor in memory fragmentation, you really only had a solid 0.75-1.5GB of space that could be kept continuously in use. That was starting to become a problem even when 32-bit was the only practical option. A lot of games saw a benefit to just having the larger address space, such that they ran better in 64-bit with only 4GB of RAM despite the fatter 64-bit pointers.

vlovich123 1y ago
I believe that's an accident of the evolutionary path chosen with syscalls. If we'd instead gone with a ring buffer approach to make requests, then you'd never need to partition the memory address space; the kernel has its memory and userspace has its and you don't need the situation where the kernel is always mapped.
- kbolino 1y ago
  Hmm. I don't understand how that would work. I think it would be possible for e.g. microkernels to greatly reduce the size of the reservation (though not to eliminate it entirely). However, I can't imagine how you would handle the privilege escalation issue without having at least some system code in the application's virtual address space that's not modifiable by the application.
  - vlovich123 1y ago
    I'm not sure how privilege escalation would be an issue since you'd never escalate privilege in the first place (I'm assuming you're talking about CPU ring privileges and not OS privileges). You'd just enqueue into the shared kernel/user space ring buffer your operations and the kernel would pick them up on its side, but you'd never jump between rings. Such a design may require at least one processor dedicated to running the kernel at all times, so it might not work on a single processor architecture. However, single processor architectures might be supportable by having the "kernel process" go to sleep by arming a timer and the timer interrupt is the only one that's specially mapped so it can modify the page table to resume the kernel (for handling all the ring buffers + scheduling). As you note, there's some reserved address space but it's a trivial amount just to be able to resume running the kernel. I don't think it has anything to do with monolithic vs microkernels.