8 ms·
Aren't 32 systems more power-efficient? It costs less energy to switch 32 transistors than 64.
by EVa5I7bHFq9mnYK 1y ago
Aren't 32 systems more power-efficient? It costs less energy to switch 32 transistors than 64.
- kimixa 1y agoOn 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.
- octoberfranklin 1y agoIt'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.
- kimixa 1y agoI 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.
- ainiriand 1y agoWhat 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.
- em3rgent0rdr 1y agoNot 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 agoI wish x32 had taken off; better performance and lower memory use. https://wiki.debian.org/X32Port https://wiki.debian.org/X32Port
- NoGravitas 1y agoI 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 agoApplications 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.
- smallpipe 1y agoWait until you hear about 8 bit systems
- em3rgent0rdr 1y agoYes 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.
- bobmcnamara 1y agoSometimes you gotta run real fast and go right to bed to save power.
- creshal 1y agoMemory 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.
- theshrike79 1y agoCompared to 64 bit? Maybe. Compared to ARM-based systems? Nope.
- chasil 1y agoSolaris 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.