Google Chrome For Linux Goes 64-bit

Noam.of.Doom writes "The Google Chrome developers announced on August 19th the immediate availability of a new version of the Google Chrome web browser for Linux, Windows and Macintosh operating systems. Google Chrome 4.0.202.2 is here to fix a lot of annoying bugs (see below for details) and it also adds a couple of features only for the Mac platform. However, the good news is that Dean McNamee, one of the Google Chrome engineers, announced yesterday on their mailing list that a working port of the Chrome browser for 64-bit platforms is now available: 'The v8 team did some amazing work this quarter building a working 64-bit port. After a handful of changes on the Chromium side, I've had Chromium Linux building on 64-bit for the last few weeks. I believe mmoss or tony is going to get a buildbot running, and working on packaging.' Until today, Google Chrome was available on both 32- and 64-bit architectures, but it appears that the latter was running based on the 32-bit libraries. Therefore, starting with Google Chrome 4.0.202.2, 64-bit users can enjoy a true x64 version!"

Comments

Serious question

[Thatmushroom]

Can someone explain the particular benefits of having a 64-bit browser? I particularly appreciate the fact that Firefox currently can't hog all of my RAM when something (oftentimes Flash) spirals out of control. Do web developers use memory beyond the 4 gig limit, and is this a godsend for them?

Re:Serious question

[faragon]

Cons:

- The benefit from passing from 8 to 16 general purpose registers is very little, and often, counterproductive, as total "true registers", the ones used for register renaming in OoOE remain the same, so with twice the general purpose registers, you halve the renaming register pool. That was specially noticeable in firsts AMD64 CPUs, and *very* noticeable on Intel Pentium D CPUs (Pentium 4 with x64 support and other minor changes), acusing of insufficient register pool volume for the OoOE operation in x64 mode. Newer CPUs, having a higher pool of registers, have less impact when executing x64 code.

- Memory and data cache wasting: Pointers take 64 bits, so unles you're doing your own memory management, with 32-bit offsets instead of using the bulk 64-bit space for adresses, you're wasting more memory, and what is worst: higher data cache usage for the same purpose, with unnecessary CPU-RAM bus overload (remember that OoOE implies data fetching! -imagine a contiguous 32 64-bit pointer vector, taking 2048 bits instead of the 1024 bits that it would take with 32-bit pointers-).

Pros:

However, for some things there is true benefit, and is that the number of registers for SSE operations have been also doubled, from 8 to 16. And because of the nature of the SSE code, which is usually less prone to jump misprediction and with less register aliasing, because of the nature of vector processing code.

Corollarius:

In my opinion a 64-bit operating system makes sense, but an application that doesn't need more than 2GB of RAM, and doesn't need to gain an extra 10% of speed up when running optimized SSE vector code, should be compiled in 32-bit mode.

Privacy Issues Disclaimer

[Zero__Kelvin]

Some quick research revealed that there are some missing features with regard to privacy that stopped me from checking it out :-( YMMV.