5 ms·

Is there a reason to run a 64-bit browser? (Other than the fact that amd64 provides more GPRs?) Do people run browser sessions that use huge amounts of memory?

• FooBarWidget 15y ago
  Yes. The 64-bit browser came with the OS.
  • dmm 15y ago
    A 32-bit browser runs just fine on all of the 64-bit OSs I know of. On all of the OSs I have experience with, compiling an app as 64-bit is the exception, done only when it needs lots of memory. What advantages does running a 64-bit browser on a 64-bit OS have over running a 32-bit browser on a 64-bit OS? Do the 8 extra GPRs bring significant performance benefits? Do individual browser processes need to address lots of memory?
    • stingraycharles 15y ago
      More memory capacity is just one of the use cases. Just to name one example, when doing string comparisons, you can use long integer comparisons under the hood. When using 8 byte longs instead of 4 byte longs, string comparisons are faster.
      • dmm 15y ago
        > you can use long integer comparisons under the hood That's interesting. Does it make up for the increased size of pointers? Caches are under a lot of pressure these days. AMD64 is a weird arch. Is it possible to use 64bit instructions with a 32bit address space?
        • mjg59 15y ago
          Yes, but it's ABI incompatible with 32-bit or full 64-bit. https://sites.google.com/site/x32abi/ https://sites.google.com/site/x32abi/ is an implementation.
        • mjb 15y ago
          > Caches are under a lot of pressure these days. More from data sizes than code sizes, at least in most performance-critical applications. Sure, bigger pointers will lead to higher miss rates in caches that contain code, but that is unlikely to prove to be a bottleneck for real-world browser use (in the current version of the real world).
• adamtulinius 15y ago
  Well, for one it would be lovely not having to clutter a 64-bit system with a ton of 32-bit libraries, just because of Adobes software being less than stellar.
  • jsight 15y ago
    Yes, and it's nice to avoid the increased memory overhead of running 32-bit GTK and 64-bit GTK. The increase in shared lib overhead is still fairly significant.
• bad_user 15y ago
  compiling as 64-bit doubles the size of longs and pointers Obese longs and pointers, imagine the horror - but, no, that's not the reason. The reason for why apps don't get compiled to 64-bits has more to do with the effort required to port said apps to 64-bits. Truth is running 64-bits apps yields other advantages than access to more than 4GB of memory - a 64-bits app has access to the processor's 64-bits instruction set and some architectures allow access to more general purpose registers, memory-mapped files are easier to implement (MongoDB, last time I tried it, was unusable on 32-bits) and performance of applications such as encoders/decoders/encryption software is increased. A 64-bits Flash would clearly benefit from the transition, even if you don't have more RAM.
  • dmm 15y ago
    Every arch I've worked with(ppc, sparc) 64bit binaries are almost universally slower than 32bit unless they use the bigger address space. > Obese longs and pointers, imagine the horror Take a break from javascript and look up how processor caches work, doubling the size of pointers increases cache pressure and can definitely make programs slower. > allow access to more general purpose registers, memory-mapped files are easier to implement I specifically mentioned more registers and a bigger address space. My question was whether this made a difference for web browsers.
    • Symmetry 15y ago
      Yes, doubling the number of registers and making SSE2 a requirement increased performance across the board (except for flash). http://www.tuxradar.com/content/ubuntu-904-32-bit-vs-64-bit-benchmarks http://www.tuxradar.com/content/ubuntu-904-32-bit-vs-64-bit-... I've never heard of a processor architecture that got a performance boost from going to 64 bits except x86-64, though.
    • bad_user 15y ago
      I specifically mentioned more registers No you haven't. Take a break from javascript and look up how processor caches work A personal attack doesn't do any good. There are techniques available to reduce pressure on the cache, but more and bigger registers gives you an immediate advantage that can't be replicated - some apps have speed gains just by recompiling. Also, 32-bits apps running on top of 64-bits are running in an emulated 32-bits environment and so they take a penalty just for that. It is true in practice that 32-bits is all you'll ever need and you won't notice the difference, but modern browsers would get a healthy boost in performance (yes, 15% matters).
• keeperofdakeys 15y ago
  Why don't we use 16 bit apps anymore, they worked? The answer is because the libraries they depend on are no longer 16 bit. Getting 32 bit code to work on a 64 bit system involves having BOTH the 32 and 64 bit versions of the library installed. Using which program you want to use, 64 or 32 bit, is not a choice like a window manager; you should use the one that is supported by your system. If your system is 64 bit, it supports 64 bit apps. The fact that it CAN run 32 bit apps is just an extra. And personally, yes, I could easily blow this limit if I allowed my normal browsing behavior to blossom (that is having lots of tabs I want to reference later and leaving them open).
• mjb 15y ago
  > Is there a reason to run a 64-bit browser? (Other than the fact that amd64 provides more GPRs?) Increased effectiveness of ASLR (Address space layout randomization) and PIE (position independent executables) is one such reason. Using ASLR and 64 bit pointers can make some common classes of attack much more difficult, and potentially infeasible. I don't think mainstream linux distributions take full advantage of them yet, though.