3 ms·

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 poi

by 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).
- dmm 15y ago
  >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 http://en.wikipedia.org/wiki/X86-64
  - cube13 15y ago
    >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.
    - copper 15y ago
      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.
    - greyfade 15y ago
      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.

by dmm 15y ago

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

dmm 15y ago
>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 http://en.wikipedia.org/wiki/X86-64
- cube13 15y ago
  >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.
  - copper 15y ago
    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.
  - greyfade 15y ago
    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.