5 ms·

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-canary-and.htm

by reidrac 12y ago

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-canary-and.html http://blog.chromium.org/2014/06/try-out-new-64-bit-windows-... 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 12y ago
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.
- Already__Taken 12y ago
  The real advantage is that is the address space randomisation that goes on for security has a way higher pool of address' to use or not use. Actually then using more ram is a bonus.
  - easytiger 12y ago
    Thanks, I've never heard of address space randomisation before: http://en.wikipedia.org/wiki/Address_space_layout_randomization http://en.wikipedia.org/wiki/Address_space_layout_randomizat... Is there a potential initial performance impact for a system with lots of RAM and long lived processes? I imagine for general dekstop use its negligible.
    - Already__Taken 12y ago
      I can't imagine why it's not like RAM has to move some read head around. Maybe in the future it could mean large ram devices can't power down disused chips to safe power but I'm sure smart people will solve that kind of this. I barely understand it myself.
      - easytiger 12y ago
        From my brief research it did/does have an impact on x86 32bit hosts but that all but became negligible on x86_64.
- jacquesm 12y ago
  If you can actually measure something like a 'crash rate' then you're doing something terribly wrong.
  - higherpurpose 12y ago
    Not necessarily. These products have hundreds of millions of users. Of course there will be a "rate" for anything. Case in point: http://bgr.com/2014/03/28/apple-android-app-stability/ http://bgr.com/2014/03/28/apple-android-app-stability/ As you can see, Google has managed to cut the "crash rate" of KitKat to less than half of Gingerbread and iOS 7.1, even if the crash rate for those is pretty low, too.
    - jacquesm 12y ago
      Sorry, but 'x crashed y% of the time' is absolutely meaningless. Crash rates for software are measured in frequency per total number of hours deployed. 0.9% to 2.5% of the time would translate into 'unusable'. And the Android crash rates there are also unsupported. Imagine if 2.5% of all bridges would collapse due to engineering errors and then they'd improve it by a factor of two and hail that as immense progress...
      - coldtea 12y ago
        >Imagine if 2.5% of all bridges would collapse due to engineering errors and then they'd improve it by a factor of two and hail that as immense progress... Only software is not like bridges, and crashes happen and do not bring the end of the world. Imaging having a new fangled machine, called a telephone, in 1930, only 1 in 10 (10%) calls where dropped mid-call. And then they managed to improve it to 2%. That's not totally unlike how it was back then (heck, the analog telephone network was like that even in the eighties in some countries I know). And yet nobody thought of the phone network as "unusable" (compared to what? some non-existing non-crashing one?), and nobody blamed engineering in general. Same for the early decades of the fax, same for the early dial-up internet, etc etc.
        12y ago

by reidrac 12y ago

userbinator 12y ago

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.

Already__Taken 12y ago
The real advantage is that is the address space randomisation that goes on for security has a way higher pool of address' to use or not use. Actually then using more ram is a bonus.
- easytiger 12y ago
  Thanks, I've never heard of address space randomisation before: http://en.wikipedia.org/wiki/Address_space_layout_randomization http://en.wikipedia.org/wiki/Address_space_layout_randomizat... Is there a potential initial performance impact for a system with lots of RAM and long lived processes? I imagine for general dekstop use its negligible.
  - Already__Taken 12y ago
    I can't imagine why it's not like RAM has to move some read head around. Maybe in the future it could mean large ram devices can't power down disused chips to safe power but I'm sure smart people will solve that kind of this. I barely understand it myself.
    - easytiger 12y ago
      From my brief research it did/does have an impact on x86 32bit hosts but that all but became negligible on x86_64.
jacquesm 12y ago
If you can actually measure something like a 'crash rate' then you're doing something terribly wrong.
- higherpurpose 12y ago
  Not necessarily. These products have hundreds of millions of users. Of course there will be a "rate" for anything. Case in point: http://bgr.com/2014/03/28/apple-android-app-stability/ http://bgr.com/2014/03/28/apple-android-app-stability/ As you can see, Google has managed to cut the "crash rate" of KitKat to less than half of Gingerbread and iOS 7.1, even if the crash rate for those is pretty low, too.
  - jacquesm 12y ago
    Sorry, but 'x crashed y% of the time' is absolutely meaningless. Crash rates for software are measured in frequency per total number of hours deployed. 0.9% to 2.5% of the time would translate into 'unusable'. And the Android crash rates there are also unsupported. Imagine if 2.5% of all bridges would collapse due to engineering errors and then they'd improve it by a factor of two and hail that as immense progress...
    - coldtea 12y ago
      >Imagine if 2.5% of all bridges would collapse due to engineering errors and then they'd improve it by a factor of two and hail that as immense progress... Only software is not like bridges, and crashes happen and do not bring the end of the world. Imaging having a new fangled machine, called a telephone, in 1930, only 1 in 10 (10%) calls where dropped mid-call. And then they managed to improve it to 2%. That's not totally unlike how it was back then (heck, the analog telephone network was like that even in the eighties in some countries I know). And yet nobody thought of the phone network as "unusable" (compared to what? some non-existing non-crashing one?), and nobody blamed engineering in general. Same for the early decades of the fax, same for the early dial-up internet, etc etc.
      - 12y ago