4 ms·

Disclaimer: I don't know too much about this field Can someone explain why exactly 64-bit is generally slower than 32-bit? I understand that more RAM will be

Disclaimer: I don't know too much about this field Can someone explain why exactly 64-bit is generally slower than 32-bit? I understand that more RAM will be used and I/O to it slowed down due to double the bits pushed around since "chunks" have double the length, which ends up being a lot of empty padding (is that correct?). But everything inside the CPU, like registers or ALUs, are 64 bits wide anyway (right?), so computing in 64-bit mode would just make use of resources that were unoccupied in 32-bit mode. Or am I missing something?

jcranmer 10y ago
The primary resource that's going to be hit is the cache. You get 8MB of cache whether you're in 32-bit mode or 64-bit mode. Switching to 64-bit mode means that you have half as much cache in terms of number of pointer fields you can store. Note this can also impact alignment of fields within structs--if you're on 64-bit, you want your pointers to appear before 32-bit fields; if you alternate, you waste a lot of extra space.
- deleted 10y ago
  [deleted]
vvanders 10y ago
Cache sizes are fixed to less things fit in L1/L2 than did before.
robert_foss 10y ago
Because addresses are longer they will take up more space, which will lead to your CPUs instruction-cache (I-Cache) being more full, which directly translates into performance losses due to needed things being evicted from I-Cache. The same is true for L1/L2/L3 caches too. The same is true to a much lesser extent for taking up more space in ram, and to an even lesser extent for reading things from storage.
- tigershark 10y ago
  This is true for non x86 architectures. Translating an x86 software to x64 brings performance benefits most of the times because of the ability to use the additional registers non accessible in x86 mode.
user5994461 10y ago
>>> Can someone explain why exactly 64-bit is generally slower than 32-bit? It's an incorrect yet popular assumption on the internet. 64 bits pointers take more space, which affects caching => Slower 64 bits architectures have more registers and instructions, and it removes the need to have an intermediate 32to64bit abstraction layer from the OS => Faster. Overall, the side effects are extremely complex. Moving an application from 32 to 64 bits is as likely to be 1% faster as to be 1% slower.
- krylon 10y ago
  This has been my experience, too, mostly. I ran both a 32-bit and a 64-bit Linux desktop on an Athlon64, both for several months, and I did not notice a difference in performance. About the only real benefit is that the system can handle more RAM (which of course is a good thing). For some applications that are very, very memory-hungry, this can improve performance dramatically, because the program no longer needs to juggle all that data and can just keep it in RAM.
CountSessine 10y ago
Because no one else has mentioned it, paging is more expensive in 64-bit. In 64-bit, the kernel uses a 3 or 4 level page table requiring 3 or 4 SDRAM accesses on a TLB miss. 32-bit kernels can get away with 2 SDRAM accesses (PDE+PTE) if they're doing 32-to-32 translation. On a ~3GHz CPU, each uncached SDRAM access will cost the CPU about 200 cycles which means a worst-case 32-bit scenario would be about 400 cycles but 64-bit could reach +800 cycles. This only applies to running a 64-bit kernel vs a 32-bit kernel; running a 32-bit process on a 64-bit kernel will incur the same page table cost as a 64-bit process.
- tigershark 10y ago
  Exactly, and I seriously doubt that in 2017 anyone is using a 32 bit OS with visual studio (I had to endure it in 2015 at work and I know very well what it means)
  - CountSessine 10y ago
    Agreed. And, while I have no evidence of this, my intuition is that the extra GPRs you get in 64-bit more than makes up for any minuscule system-wide performance hit 64-bit long-mode paging imposes.
- dmitrygr 10y ago
  Modern CPUs heavily cache (in L2 & L3) the page table entries (some even speculatively load them into cache), so actual DRAM accesses are rarely needed.

jcranmer 10y ago

The primary resource that's going to be hit is the cache. You get 8MB of cache whether you're in 32-bit mode or 64-bit mode. Switching to 64-bit mode means that you have half as much cache in terms of number of pointer fields you can store. Note this can also impact alignment of fields within structs--if you're on 64-bit, you want your pointers to appear before 32-bit fields; if you alternate, you waste a lot of extra space.

deleted 10y ago
[deleted]

vvanders 10y ago

Cache sizes are fixed to less things fit in L1/L2 than did before.

robert_foss 10y ago

Because addresses are longer they will take up more space, which will lead to your CPUs instruction-cache (I-Cache) being more full, which directly translates into performance losses due to needed things being evicted from I-Cache. The same is true for L1/L2/L3 caches too. The same is true to a much lesser extent for taking up more space in ram, and to an even lesser extent for reading things from storage.

tigershark 10y ago
This is true for non x86 architectures. Translating an x86 software to x64 brings performance benefits most of the times because of the ability to use the additional registers non accessible in x86 mode.

user5994461 10y ago

>>> Can someone explain why exactly 64-bit is generally slower than 32-bit? It's an incorrect yet popular assumption on the internet. 64 bits pointers take more space, which affects caching => Slower 64 bits architectures have more registers and instructions, and it removes the need to have an intermediate 32to64bit abstraction layer from the OS => Faster. Overall, the side effects are extremely complex. Moving an application from 32 to 64 bits is as likely to be 1% faster as to be 1% slower.

krylon 10y ago
This has been my experience, too, mostly. I ran both a 32-bit and a 64-bit Linux desktop on an Athlon64, both for several months, and I did not notice a difference in performance. About the only real benefit is that the system can handle more RAM (which of course is a good thing). For some applications that are very, very memory-hungry, this can improve performance dramatically, because the program no longer needs to juggle all that data and can just keep it in RAM.

CountSessine 10y ago

Because no one else has mentioned it, paging is more expensive in 64-bit. In 64-bit, the kernel uses a 3 or 4 level page table requiring 3 or 4 SDRAM accesses on a TLB miss. 32-bit kernels can get away with 2 SDRAM accesses (PDE+PTE) if they're doing 32-to-32 translation. On a ~3GHz CPU, each uncached SDRAM access will cost the CPU about 200 cycles which means a worst-case 32-bit scenario would be about 400 cycles but 64-bit could reach +800 cycles. This only applies to running a 64-bit kernel vs a 32-bit kernel; running a 32-bit process on a 64-bit kernel will incur the same page table cost as a 64-bit process.

tigershark 10y ago
Exactly, and I seriously doubt that in 2017 anyone is using a 32 bit OS with visual studio (I had to endure it in 2015 at work and I know very well what it means)
- CountSessine 10y ago
  Agreed. And, while I have no evidence of this, my intuition is that the extra GPRs you get in 64-bit more than makes up for any minuscule system-wide performance hit 64-bit long-mode paging imposes.
dmitrygr 10y ago
Modern CPUs heavily cache (in L2 & L3) the page table entries (some even speculatively load them into cache), so actual DRAM accesses are rarely needed.