Hacker News Reader

Comment by codedokode | Hacker News Reader

I think that it would be better if I could use 64-bit kernel with 32-bit applications.

32-bit applications are better in almost every aspect: they use smaller ints and pointers and use less memory, they can be used on both 32-bit and 64-bit systems, they don't waste energy on computing extra bits. The only disadvantage is that they cannot use more than 2Gb of RAM, but almost every aplication I use doesn't need so much RAM. On x86, 32-bit apps also have slightly less GPRs.

So the perfect solution would be a 64-bit kernel with mostly 32-bit applications except for those cases when you need more than 2Gb of RAM.

But instead many developers refuse to provide 32-bit versions of applications for Linux, and provide worse 64-bit versions. And Linux distributions compile everything for 64-bit, even if the application is never supposed to use even 1 Gb of RAM.

So everything is wrong with 64-bit support in Linux.

View on HN

You can multi-arch a distribution, also there's x64_32 (aka x32) which does exactly what you propose [0].

Running the processor in x64 mode allows wider swaths of data to be processed per clock, which really allows higher performance in data-heavy/CPU bound cases, but horses for courses, definitely.

[0]: https://en.wikipedia.org/wiki/X32_ABI

> You can multi-arch a distribution

I use multi-arch, but it is buggy. Several times, when trying to install a 64-bit library, apt was suggesting to remove tens or hundreds packages to satisfy the dependencies. That included the packages that I have installed manually and it is strange that apt tries to remove them.

Also, when using multi-arch, you can accidentally install a 32-bit kernel and then half of applications stop working.

x64_32 never really took off and there was some discussion of removing the support in the past: https://lwn.net/Articles/774734/

Any particular reason for that? Anyone knows?

Anyone has actual experience using it? Is it hard to set up? Does it have compatibility issues with plain x64? Gains not worth additional complexity?

I’ve really never seen it used or any guides on how to create a system/software built that way.

Wow,

That feels like reading that post on why Visual Studio wasn't 64 bit back in the days

https://web.archive.org/web/20160309232651/http://blogs.msdn...

BTW: Recently VS started being 64bit.

> note that this applies only to x86, on ARM 64-bit mode doesn't provide more GPRs and is even more useless

It does. The 32-bit ARM architecture has 15 GPRs (plus the instruction pointer which is sort of treated as a GPR by many instructions), while the 64-bit ARM architecture has 31 GPRs (plus one which can either be a constant zero register or the stack pointer depending on the instruction).

> Another option would be to compile apps in 64-bit mode, but use 32-bit wide ints and pointers. This way the RAM could be saved too.

There's a third mode for x86 Linux which does exactly that, but it's never been popular.

Strange, I thought that all RISC CPUs typically have 32 registers. I guess I was wrong about ARM.

Everything you said about memory space & bandwidth is 100% on point.

However: arm arch 32 has 14 general purpose registers (including the link register). arm arch 64 has 31 general purpose registers (also including the link register).

I also doubt there are real power savings in modern out of order processors. The few transistors saved in the register file and ALUs are just dwarfed by everything else. Heck, look at how much of a modern soc like the M1 is used by the compute complex compared to everything else.

Reply on news.ycombinator.com