
64-Bit Chrome for Windows - Garbage
http://googlesystem.blogspot.com/2014/06/64-bit-chrome-for-windows.html
======
reidrac
Chromium blog (the actual source) explains why 64-bit windows version is
interesting: [http://blog.chromium.org/2014/06/try-out-new-64-bit-
windows-...](http://blog.chromium.org/2014/06/try-out-new-64-bit-windows-
canary-and.html)

TL;DR: This version improves on speed (processor optimizations related),
security (windows features only available in 64-bit) and stability (they don't
say why, could be related to windows itself).

~~~
userbinator
_crash rates for the the renderer process (i.e. web content process) are
almost half that of 32-bit Chrome_

I wonder how many of those crashes are due to running out of memory, because
it otherwise seems quite odd that the 32-bit version would "crash more",
unless they (accidentally?) fixed some bugs in the porting process.

Realistically, this means a browser that can use more than ~3GB of RAM, and
that has its advantages and disadvantages.

~~~
jacquesm
If you can actually measure something like a 'crash rate' then you're doing
something terribly wrong.

~~~
justinschuh
I think you're misunderstanding the context. A percentage of users opt in to
crash reporting, and from that we see all manner of crashes on user systems.
The biggest causes in Chrome tend to be: third-party software (i.e. plugins
and injected hooks), intentional termination of web content to prevent
resource exhaustion (e.g. out-of-memory), and unstable hardware (e.g. bad
memory).

~~~
jacquesm
Sorry, but that this included third party software, intentional termination to
prevent resource exhaution and unstable hardware was not evident in the
sentence:

"crash rates for the the renderer process (i.e. web content process) are
almost half that of 32-bit Chrome"

That sort of implied (to me) that this was a measure of instability of Chrome,
not of the surroundings.

~~~
justinschuh
Users generally don't know or care if the issue is a bug in Chrome or not. To
them the problem is just that Chrome is not working. So, we try to fix it
where we can. We have code in Chrome to block third-party hook DLLs that we've
identified as making the the browser unstable. We have watchdog code to
prevent excessive resource consumption and hangs caused by misbehaving web
content or plugins. And while we can't fix bad hardware, we do have signals
that attempt to narrow it down as a cause.

That's not to say that some portion of crashes in Chrome are not caused by our
own bugs that slipped through our various QA and testing processes. Certainly,
those do exist, but in terms of crash rates they are dwarfed by the causes I
listed previously.

------
ComputerGuru
Nitpick correction for many of the comments here: if I'm not mistaken, Chrome
already does/can use more than 3 GiB of RAM with the 32-bit binaries in
Windows. Because of how its process sandboxing feature works, it is _each
helper process_ (ie tab) that is restricted to 3 GiB, plus the master process
that manages (but does not render) them. That's why they've been able to get
away with not making the jump to 64-bit for all these years.

~~~
wil421
Very interesting, I wonder what kind of tab could be 3GB?

Do you know why they had a 64-bit Chrome for Linux since 2009? Why wouldnt
they want to switch for Windows/Mac sooner. I bet the user base is greater.

~~~
pornel
1\. It's not always single tab. JS heap may need to be shared between multiple
tabs due to sharing of objects via `window.opener` and other leaky cross-frame
hacks.

2\. The process will sooner run out of _addresses_ in the 3GB space rather
than actual memory. After running for a while a process may end up with
objects allocated all over the address space, so that there isn't enough
contiguous address space free for new allocations, even though there's still
plenty of free memory in small chunks between live objects.

~~~
mason55
Wouldn't surprise me if Chrome defragments individual tab heaps

------
bhouston
This is huge for us. Desktop 3D applications were one of the first to move to
64 bit. We have been suffering with 32 bit limitations with
[http://Clara.io](http://Clara.io) and while it works, getting access to more
than 1 GB of ram for JavaScript would be amazing.

------
euank
What would be great is if Google supported other 64-bit browsers on windows.
Mozilla doesn't really officially support it, but they've provided 64-bit
nightly builds for quite a while now. For example, the current nighly 64-bit
can be found here:
[https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/late...](https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-
mozilla-central/firefox-32.0a1.en-US.win64-x86_64.installer.exe)

Flash, Java, Silverlight, and so on all have 64-bit variants which work, but
there's just no way to get the Google Talk and Hangouts plugin to work on
those builds of Firefox.

Seeing the title gave me a bit of hope until I thought "No, of course, Google
just bundles the plugin anyways... not like they'll publish a download link
for a 64-bit build". I wouldn't even care if you had to click through several
"Other system / Select custom download" links, if only it were available at
all.

I feel like we have a chicken-egg problem. Firefox isn't offering 64-bit
prominently because plugins have terrible support for it, and plugins don't
support it because it doesn't exist yet... But, unlike Firefox, plugins can
offer 64-bit compatible versions without angering a large number of users.
Really, the ball should be in their court, Google included, to provide the
options.

------
wfunction
How is NaCl going to fare in the 64-bit version, given that segmentation isn't
available in x64 mode?

~~~
leorocky
Why is segmentation important to Native Client?

~~~
sanxiyn
Native Client uses segmentation on x86 32-bit. Quoting from the paper:
[http://research.google.com/pubs/pub34913.html](http://research.google.com/pubs/pub34913.html)

"The main contributions of this work are: ... using x86 segments for ...
reduced overhead."

------
cyounkins
I thought the main problem with porting software to 64-bit was the bad
practice of developers assuming the sizes of types. Since this was Google and
the project is relatively recent, I'm assuming that is not the reason.

Why couldn't you take the chromium source (and dependencies) and compile them
for x64 months ago?

~~~
spatz
As the blog post says, the linux version has been 64-bit since 2009. So the
problem must be windows API, not type sizes.

~~~
lloeki
A bit of history: osx [0] and windows [1]

IIRC most issues revolve around plugins and performance (notably V8), possibly
not directly because of type sizes but similar low level stuff that hampers
JS-to-the-metal optimisations.

Still waiting on OSX though.

[0]:
[https://code.google.com/p/chromium/issues/detail?id=8606](https://code.google.com/p/chromium/issues/detail?id=8606)

[1]:
[https://code.google.com/p/chromium/issues/detail?id=18323](https://code.google.com/p/chromium/issues/detail?id=18323)

------
higherpurpose
I'm guessing they finally did it now because ARMv8 hardware is coming, and
they wanted to have Chrome for Android with 64-bit support for the improvement
in performance and crash rate. So they decided they might as well do it for
all operating systems now.

~~~
justinschuh
There were numerous factors, but that wasn't one of them. The biggest delays
were things like the build toolchain and logistics. For example, Microsoft's
toolchain couldn't even build a working, optimized, 64-bit Chrome binary until
sometime last year.

------
unexistance
offline version URL, DEV

[https://www.google.com/chrome/browser/index.html?extra=devch...](https://www.google.com/chrome/browser/index.html?extra=devchannel&standalone=1)

------
ulfw
Kind of ridiculous how late this comes. Also with Chrome not working well with
Windows' HiDPI settings, I am not sure why folks on Windows would go with
Chrome over Firefox frankly.

------
scrollaway
As a Linux enthusiast, I cringe every time I read "year of the Linux desktop".
(Bear with me, this is on-topic)

Linux is a very usable OS _today_. Windows, comparatively, is a much less
usable OS. USB drivers that need 3 minutes to set up every time I plug my
mouse in a different port. More issues with sound than there are with
Pulseaudio. And, yes, this is a huge peeve of mine: Only a tiny fraction of
windows software is ever ported to 64 bit. WTF?

Almost all linux software is readily available on 64 bit, as 64 bit; this
includes Chrome/Chromium from the very, very early days. So now, a major web
browser was released as 64 bit on Windows. Congratulations. Maybe 2014 will be
the year of the Windows desktop.

~~~
stinos
_Windows, comparatively, is a much less usable_

I wouldn't call it _much less_ usable, depends on what you're used to I
guess.. Actively using both, each for their own task, I find them on par with
each other. But I don't expect Windows too give me a super easy to setup
server with a mighty commandline, and I don't expect Linux to give me a super
smooth Desktop UI that can be used as a digital audio/video workstation, for
instance. Cause they both suck at those tasks equally as it's far from their
target experience. And I also don't have the WTF feeling you have as I never
had the problems you talk about: _three_ minutes? Really? _More_ issues than
Pulseaudio? Almost sounds like you try to run Windows 7 on an old pentium with
crap drivers :P

~~~
scrollaway
I'm running Windows 7 on a current top of the line box.

Speaking of that, when I swapped out my old motherboard for a new one, Windows
refused to boot, giving me a bluescreen every time. I googled around and found
that this was, in fact, a very common issue and the only solution is a full
reinstall. Woah.

More issues than Pulseaudio, yes. In fact, I have zero issues with Pulseaudio
and plenty of issues with Windows. Not like stuttering, but devices not being
recognized and a terribly confusing UI when it comes to, for example,
switching sound playback devices (getting sound to work on my TV has been an
awful experience).

Every time I have to boot into it it's an awful, awful experience. Here is
just ONE reason why: [https://superuser.com/questions/33142/ctrlbackspace-
inserts-...](https://superuser.com/questions/33142/ctrlbackspace-inserts-a-
small-box-instead-of-erasing)

~~~
pling
If you sysprep generalize the machine before you swap the board it'll work
afterwards. It's like moaning that your brain transplant resulted in you not
being able to move your arms or something similar.

~~~
4ad
The analogy is unsound, you can do this with any Linux/BSD/Solaris system just
fine. It's Windows who requires a more complex procedure here.

So yes, it's user's fault, but the point is that in this particular instance
Linux _is_ more user friendly compared to Windows. The user needs _more_
knowledge and expertise to do the same operation with a Windows machine
compared to a Linux machine.

~~~
pling
I disagree.

If you take the disks out of a Dell and stuff them in an HP machine with the
same chipset, Linux gives you no guarantee the Ethernet ports will be the same
order on startup.

It's just different and you see the differences as misfeatures.

~~~
scrollaway
> Linux gives you no guarantee the Ethernet ports will be the same order on
> startup

Systemd does.

~~~
pling
a) Debian stable, Ubuntu, rhel6 don't have systemd. So no our servers don't.

b) it can't assume heuristics like that if the vendor changes so no it can't.
This was based on a complete data transplant.

~~~
scrollaway
When I complain about Windows, I'm expected to complain about things that are
still present in the latest version of windows (8.1 currently), not things
that are no longer an issue since XP. In return, I expect you to do the same
when complaining about Linux.

This is a solved problem and systemd is coming to debian as well.

~~~
pling
In that case that would be complaining about windows 9. There are no
mmainstream distributions shipping systemd yet.

~~~
scrollaway
Windows 8.1 is not mainstream either, compared to 7.

~~~
pling
I'm sitting in an office with 120x 8.1 systems at the moment so...

~~~
scrollaway
And I'm sitting in an office with over 200 Fedora and Arch Linux machines.
What's your point?

