Slashdot Mirror
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!"
Chromium is the name we have given to the open source project and the browser source code that we released and maintain at www.chromium.org. One can compile this source code to get a fully working browser. Google takes this source code, and adds on the Google name and logo, an auto-updater system called GoogleUpdate, and RLZ (described later in this post), and calls this Google Chrome.
It's like calling Firefox proprietary because you've been shipped an actual binary that uses their TM'd logo, not the one you'd get by default when compiling it from source. And the auto-update mechanism is Windows-only as far as I know (my Debian install of Chrome correctly integrates into the APT system, as it should be) so it shouldn't worry you a lot if you're an Ubuntu user.
For the same reason that text editors might be 32 or 64-bit and not 16-bit. It's what the OS and hardware directly supports. Most computers shipped in the last four or five years are 64-bit and can support 64-bit operating systems. Even Microsoft has said that Windows 7 will be their last operating system to support 32-bit. It makes sense to start developing native 64-bit versions of software instead of sticking with 32-bit and using a compatibility library or layer to further complicate things or possibly screw up or need to debug. There's no direct benefit other than it's the native number of bits for your hardware, but that makes it the right thing to do.
This is why I think leading edge distros like Ubuntu should stop supporting 32-bit and only distribute 64-bit versions of their distros. The only computers that still are 32-bit are either embedded systems or older legacy computers. We need to move on.
Cory Doctorow talking about cloud computing makes as much sense as George W Bush talking about electrical engineering.
Really? I'm posting this from a 32-bit legacy computer that runs 32-bit Ubuntu just fine. I've got a 'legacy' machine on the right with XP and an Nvidia GForce 5600, also 32 bit, that is even more useful, being a Pentium. You are about 4 years too early to even begin to talk about end-of-life for 32 bit.
I couldn't really find numbers, but I supect ditching 32 bit would entail throwing out at least half of the computers currently in use...
I don't have the numbers to back it up, but I'm fairly certain that a sufficiently large portion of computers use 32-bit to make your presumption completely infeasible for the next few years. They were still selling 32-bit machines two years ago, and people can't reasonably be expected to retire those machines until 2011, and many will still be perfectly useful until 2013 or even 2015 with a few repairs.
Meanwhile, you can keep on living in your fantasy world where hardware can magically upgrade itself to run the latest and greatest software.
I believe it's the JIT engine for javascript, which by it's very nature needs to generate native code and is therefore not so simple to port. The rest of it should compile cleanly on 64, at least webkit does anyway.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
An advertising company wants to install software on your computer. They profit by data aggregation and accumulation by seeing where on the map you are interested in going, what friends you chat with, what all the files on your computer are and how you search for them, and oh, everything you look at on the internet. Click here to install.
64bit also vastly speeds up long and double math. It doesn't really apply to a browser, but if you were using 64bit integers to store currency amounts, you'd notice a huge speedup. Adding/subtracting from longs is one thing that SSE probably won't help. ;)
No speedup for these reasons, at all:
1) In the case of using 64-bit 2's complement integer registers, you're able to speed-up your 64-bit interger code because operating with 64-bit integers without chaining 32-bit results on the 32-bit CPU case. However, you're missing the point that most heavily computing, such as RSA's big numbers, DES, AES, Blowfish, etc. doesn't use general purpose register but vector SIMD opcodes (e.g. SSE*), already available in the 32-bit mode (with 8 instead of 16 registers, yes), which is faster than 64-bit integer operations.2) Floating point ("double math") remains almost the same, but with also 8 additional SSE registers.
3) Related to "adding/substracting from longs": In 32-bit mode, a SSE3 -or later- functional unit can execute *four* 32-bit instructions per clock (fetching 128-bit data at once), while already being able to execute from 2 to 4 integer + load/store instructions (e.g. Core2Duo or K8), so it would be faster still while chaining 32-bit results.