Hacker News Reader

Comment by dmm | Hacker News Reader

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.

View on HN

     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.

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.

Reply on news.ycombinator.com