|
|
|
|
|
|
by gsnedders
3422 days ago
|
|
|
> Incidentally, wouldn't the exclusive use of 64-bit pointers (and size_t) prompted by the inflated need in large address spaces lead to an ever more increasing demand for memory (due to in-memory objects being now bigger in size)? Yes. This is the reason why some people have pushed for "x32" support, and why Linux 3.4 and above supports it (tl;dr: x64-64, but with 32-bit pointers: you get all the advantages of x86-64 without the pointer bloat). |
|
|
But wait. This could actually work out really well for Chrome, since it's multiprocess, and each process will likely consume <4GB.
That is really cool.
I've been wondering why Chrome on my T60 (64-bit but only 3GB RAM visible due to chipset stupidity) is noticeably, perceptibly slower and far more ready to swap itself to death than on my T43, which practically flies. (The T60 has a Core2 T7200, the T43 a Pentium M.) Bigger pointers sounds like a very interesting theory, especially considering the "enterprisey" nature of Chrome's C++ code - piles of vtables and pointers to pointers to callbacks to pointers to...