[Koshkin]

Good for Arch, I guess. Still, there's plenty of uses for 32-bit platforms. Also, much of the attractiveness of Linux (the kernel) and the GNU software has always been in their excellent support for various architectures and platforms.

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)?

[gsnedders]

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

[i336_]

Except processes can't use >4GB virtual memory.

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

[StringEpsilon]

All modern x86* CPUs are 64bit anyway and if this move means maintainers are freed up a bit, then I think it's worthwhile for the distro as a whole.

Arch isn't really meant to be that one distro you can stick on a PC from the early nineties anyway. There are much more suitable distros for legacy hardware.

And about the downsides of 64bit: I think the vastly improved address space offsets the improved memory use by orders of magnitues. My Desktop has 8 times as much useable RAM as it could have with 32bit - but 32bit datatypes are only double in size.

[Koshkin]

> the early nineties

64-bit computers started gaining popularity in the consumer market only, what, 5 years ago?

[mastax]

What do you mean gaining popularity?

Athlon 64 came out in 2003, Pentium 4F in 2005. I'll concede that 32-bit Atoms were reasonably popular in certain market segments, but hasn't generally every consumer computer been 64-bit for over 10 years?

[Koshkin]

Sure, but the point has nothing todo with the availabilty or popularity of 64-bit CPUs. Rather, it has to do with the amount of memory deemed necessary in a computer. As far as I remember, Windows Vista, which was released into the wild just about 10 years ago, was predominantly 32-bit, 64-bit intalls, just like with XP, being more of a curiosity. Few consumer devices had more than 2GB of RAM back then.

[wolrah]

The Athlon 64 was released in September 2003, the Prescott Pentium 4 in February 2004, and the iMac G5 in August 2004.

Desktop CPUs have been basically guaranteed to be 64 bit since 2005.

The Pentium 3 derived Pentium M and Core Solo/Duo delayed wide mobile adoption of 64 bit until Core 2 came around in July 2006. I'd guess by 2007 you could probably safely assume 64 bit across all but the cheapest laptops as well.

tl;dr: Aside from a few Atom-powered netbooks 64 bit has been standard in anything resembling a normal computer for around a decade.