Hacker News Reader

Comment by dmm | Hacker News Reader

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?

EDIT: Is it standard practice to compile everything as 64-bit on AMD64? This is not the case on early 64-bit arch such as sparc and ppc. The reason for this is that compiling as 64-bit doubles the size of longs and pointers and is only an advantage when you need to address large amounts of memory.

For example if you run linux on ppc64 almost all of your userland is probably compiled 32bit.

View on HN

     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.

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.

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-... I've never heard of a processor architecture that got a performance boost from going to 64 bits except x86-64, though.

     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).

>No you haven't.

In my top post I said:

> Other than the fact that amd64 provides more GPRs?

You should read what you're replying to.

> Also, 32-bits apps running on top of 64-bits are running in an emulated 32-bits environment

That's bullshit, at least on AMD64. "Because the full 32-bit instruction set remains implemented in hardware without any intervening emulation, existing 32-bit x86 executables run with no compatibility or performance penalties" [0]

> but modern browsers would get a healthy boost in performance

Have you tested this?

[0] http://en.wikipedia.org/wiki/X86-64

>That's bullshit, at least on AMD64. "Because the full 32-bit instruction set remains implemented in hardware without any intervening emulation, existing 32-bit x86 executables run with no compatibility or performance penalties" [0]

Which is true if you're running a 32-bit kernel on top of the 64-bit processor.

If you're running a native 64-bit kernel, then the kernel needs a 32-bit emulated layer that runs between the native kernel and the userland application that handles virtual memory address translations(32-bit executables are still limited to 4 gigs of RAM, but can be physically located anywhere), system call translations, etc. That's a potential performance hit.

You also need to keep 32-bit and 64-bit shared libraries, and then keep them (more or less) in sync - admittedly, linux distros do manage that more or less invisibly.

Mind you, when it comes to nvidia cards and the claims that newer versions of flash make about hardware video decoding, it's not funny anymore.

There's no emulated layer. The CPU offers a 32-bit compatibility mode that works akin to 8086 virtual mode on earlier processors. The 64-bit kernel just sets a few flags and drops to 32-bit mode, switches tasks and goes. No overhead.

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.

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.

> 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.

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).

Yes. The 64-bit browser came with the OS.

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?

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.

> 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?

Yes, but it's ABI incompatible with 32-bit or full 64-bit. https://sites.google.com/site/x32abi/ is an implementation.

> 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).

Reply on news.ycombinator.com