Hacker News Reader

Comment by EVa5I7bHFq9mnYK | Hacker News Reader

Aren't 32 systems more power-efficient? It costs less energy to switch 32 transistors than 64.

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.

I wish x32 had taken off; better performance and lower memory use.

https://wiki.debian.org/X32Port

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.

> 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.

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.

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.

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.

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.

True, you don't have to go full microkernel just to have messages passed though a buffer. However, if the buffer is shared by all processes, it does need to have some protection. I guess you could assign one buffer per process (which might end up using a lot of physical RAM), and then just crash the process if it corrupts its own buffer. The bigger issue with this approach might be adapting to asynchrony though.

It wouldn't be by all processes. One per process just like with io_uring. Not sure how it would end up being all that much physical RAM - you get a lot more memory mapped when you just start a process. Page faults might be another tricky corner case.

I have for a while wondered why we don't have "security core"s that are are really slow, but don't have caches or speculative execution so you can run security critical code without having to worry about CPU timing attacks

I think that would be of little help if the faster, less-secure cores have access to the same memory system as the secure cores. If the JavaScript engine of your browser runs on the fast cores, and you're visiting a malicious website, then vulnerabilities due to speculative execution on the fast cores could still leak information that was written by the slow cores. And you really wouldn't want to run the JS engine on cores without caches and speculative execution, at least not for everyday browsing.

What problem are you trying to solve?

If you just want constant-time operations, you just need dedicated instructions. Maybe they run on dedicated cores, but that's an implementation detail. I think this is a good idea, and it feels like we're heading this way already, more or less.

If you want to address all of the vulnerabilities that have arisen, you need full isolation. As mentioned in a sibling comment, you can't share any memory or caches etc. Each "security core" would have to be fully isolated from every other core, including every other security core. And you also need to segregate out "sensitive" code and data from non-sensitive code and data. When all is said and done, I don't see how we're talking about anything less than scrapping all existing ISAs, and perhaps even von Neumann architecture itself. I'm sure there are some middle-ground solutions between where we are today and this extreme, but I think they're going to look more like TPM/Secure Enclave than special cores, and they're only going to partially address the vulnerabilities.

You don’t really need a security core with my proposal. By ensuring that kernel and userspace code run in completely different page table domains, it removes the possibility for a meltdown style attack precisely because the memory was mapped alongside userspace and relied on CPU protections to keep it secret (those protections got thwarted by speculative execution). It’s actually a software design flaw.

It depends on the kernel architecture. 4G/4G kernels weren't the most common thing, but also weren't exactly rare in the grand scheme of things. PowerPC macOS (and x86 in macOS before they officially released Intel based mac hardware) were 4G/4G for example. The way that works under x86 is that you just reserve a couple kernel pages mapped into both address spaces to do the page table swap on interrupts and syscalls. A little expensive, but less than you'd think, and having the kernel and user space not fight for virtual address space provided its own efficiencies to partially make up the difference. We've been moving back to that anyway with Kernel Page Table isolation for spectre mitigations.

And 3-1 wasn't really experimental. It was essentially always that way under Linux, and had been supported under Windows since the late 90s.

Yeah, "experimental" may not be the right word, but actually getting to use the 3-1 split required all of the following: at least 3GB of physical RAM (obviously), the O/S booted with /3GB flag, and the application in question linked with /LARGEADDRESSAWARE flag (and not mishandling the high bit of a pointer). Many video games towards the end of the 32-bit era were built this way tbf, though they still generally do better on 64-bit Windows/Wine anyway.

On anything but the smallest implementations, the 32 vs 64bit alu cost difference is pretty tiny compared to everything else going on in the core to get performance. And assumes the core doesn't support 32-bit ops, leaving the rest of the ALU idle, or does something like double pumping.

Really the ALU width is an internal implementation detail/optimisation, you can tune it to the size you want at the cost of more cycles to actually complete the full width.

It's the MMU width, not the ALU width, that matters.

Lots of machines are capable of running with 32-bit pointers and 64-bit integers ("Knuth mode" aka "ILP32"). You get a huge improvement in memory density as long as no single process needs more than 4GB of core.

I assume you mean "pointer width" - ala the x32 ABI and similar, and more about cache use than "Switching Transistor Count".

But really that's a software/OS level thing, and though the benefits have definitely been shown, the seem small enough to not be worth the upheaval.

Though possibly related, larger pages have been shown to have significant speedups without changing the ABI (as much, at least mmap() and similar will have slightly different specifics). IMHO the only possible "benefit" to 4kb page sizes is to (ab)use it to trap things like array overruns - though using that is a poor substitute for /real/ bounds checking - a lot can go wrong within 4kb, after all.

What makes you think that a 32 bit system has 32 transistors? For example, from the top of my head, the pentium pro had a 86 bit direction bus and a 64 bit data bus.

Sometimes you gotta run real fast and go right to bed to save power.

Memory buses are negligible, compared to everything else going on. Especially in a SoC that has not just a CPU, but 20 other devices as well.

Solaris uses 32-bit binaries in /bin and /usr/bin for most of POSIX.2, even though it requires the x86-64 architecture.

I saw this last in SmartOS.

Wait until you hear about 8 bit systems

Yes and no. A problem with 8-bit and 16-bit for desktop and servers is the limited memory address space, so the compiler has to insert extra instructions to deal with things like updating the segment registers. And likewise if you need to do higher-bit math then the compiler again has to insert extra instructions. Those extra instructions clog up the pipeline, but aren't needed if your largest program's working memory set and the largest precision math you generally need fits within the ISA's bit size. Unless you are doing scientific computing or other large-memory set tasks like Blender (which dropped 32-bit support), then 32-bit really is good-enough.

I couldn't tell if your comment was a joke, but it is worth mentioning the 8-bit microcontrollers like TinyAVR still fill a niche where every joule and cent counts.

Compared to 64 bit? Maybe.

Compared to ARM-based systems? Nope.

Reply on news.ycombinator.com