Hacker News Reader

Comment by codedokode | Hacker News Reader

Would not it be easier just to use 32-bit x86 arch instead of 64-bit? Pointer compression looks like a solution for a problem that should not exist in the first place. I saw the arguments against this in [1] but they look very weak ("We cannot use 32-bit arch because Chrome has switched to 64-bit and because there is an OS nobody is using that doesn't allow this").

Why not make 64-bit Chromium for those who has over 16 Gb of RAM and 32-bit for normal people?

[1] https://docs.google.com/document/d/10qh2-b4C5OtSg-xLwyZpEI5Z...

View on HN

Realistically the limit for 32bit apps isn't 4GB, but considerably lower. The OS mapping takes out like 1gb at least. Then you have shared libraries mapped in. You want space for aslr. Mmapping files. Etc.

Leaving available memory aside, for a lot of optimizations it's useful to have plenty virtual memory space - which is definitely not the case in 32bit.

Basically, just because js bytecode doesn't need more than 4gb, doesn't mean no other part of chrome needs more.

That's correct, although 32-bit processes on a 64-bit operating system (as are still supported on Windows and Linux, and were supported on macOS until Catalina) can effectively have 4GB.

Back when I was still using Windows, you could boot the 32-bit OS with "/3GB", which would make the kernel/user split 1GB/3GB instead of the original 2GB/2GB default - but it was optional and explicit, because quite a bit of software failed; I would guess that changed with time, but likely a similar "/4GB" switch for 32-bit apps on 64-bit OS would also expose assumptions about the address space layout ...

It'd also make syscalls a bit more expensive...

x64 has 16 general purpose registers, while x86 only has 8 general purpose registers. So even with the extra overhead of 64-bit pointers, x64 code still ends up being faster.

In terms of speed, it's:

1. x64 with compressed pointers

2. x64

3. x86

In terms of actual production usage, it's:

1. x64

2. x64 with compressed pointers

3. x86

So x86 is the slowest and the least used among the three. And frankly it would be very difficult to hire talent in 2020 if you're targeting the x86-64 platform but chose to use the legacy x86 mode for whatever reason.

That would mean the entire process would be limited to 4GB of ram which is pretty awful considering multiple Javascript VMs run in the same process which could have 4GB of memory each. That way the RAM limit is significantly below 4GB per application.

+1. In fact even the JavaScript heap isn't limited to 4gb, just the space that pointers can point to. For example, we allocate large typed arrays outside of the V8 heap.

Recent macOS Catalina threw away 32-bit support; Ubuntu LTS as of 20.04 is removing almost all of the 32-bit libraries (with a few exceptions that would let Wine/Proton keep running, IIRC). It will eventually happen in Windows as well; 16-bit code was exceptionally fast and compact when it was suffcient.....

Reply on news.ycombinator.com