4 ms·

I might be wrong, but aren't there much more registers available in 64 bit mode on intel? That potentially outweighs any memory increase because it can reduce c

I might be wrong, but aren't there much more registers available in 64 bit mode on intel? That potentially outweighs any memory increase because it can reduce cache pressure. Or is this mostly alleviated by register renaming and other tricks?

ygra 10y ago
Rico responded to that question on one Reddit discussion about the issue once: https://www.reddit.com/r/programming/comments/3zddyh/revisiting_64bitness_in_visual_studio_and/cylewoo/?context=3 https://www.reddit.com/r/programming/comments/3zddyh/revisit... In short, due to VS having an already large working set it hurts more to let it grow even larger than having more registers helps. I also think that many people took his stance as »32 bit should enough for anybody and no one should move to 64 bit«, whereas it was more a »performance characteristics for different types of applications are very different and for Visual Studio it's a choice that will make things slower«. Admittedly, that doesn't appease the people who experience crashes, although extensions like ReSharper are often more wasteful with memory than the IDE itself and those could just as easy be put in a separate process. Although for JetBrains it's probably a marketing argument to push ReSharper users to Rider (which actually uses an out-of-process model and thus not have the problem).
- scott_s 10y ago
  Like other people, I remain unconvinced by his arguments. The main problem is that no one can say for certain what will actually happen, as the 64-bit version does not exist. I also care about performance (for a living!) and I've been humbled enough times by "for sure this is what will happen" type thinking that I know it's just too hard to predict with certainty what will happen with such a complex interaction of parts. Specifically, I'm skeptical of the argument that more registers will not help, but no one can test the arguments empirically. Which is always dangerous ground. I do, however, buy people's arguments that they are feeling real pain by the memory limitations. Even if 32-bit is faster at the moment, I think it's a short-sighted decision to not port to 64-bit. First, the memory issue that everyone has brought up. Two, I find it likely that over time, using the now-standard bitedness (I know that's not a word, forgive me, I have a cold and mind is foggy) will yield benefits because it's the common path in the processor. (ygra, I know you're not necessarily in agreement with everything Rico said, so I'm not really arguing with you.)
masklinn 10y ago
> I might be wrong, but aren't there much more registers available in 64 bit mode on intel? It's not "intel", it's x86. x86_64 has twice the number of registers.
- digi_owl 10y ago
  Never mind that it was AMD that extended x86 to support 64 bit, while Intel was off chasing its own tail with Itanium.
- wolfgke 10y ago
  > x86_64 has twice the number of registers The "typical ALU instructions" as add, cmp etc. can now encode 16 registers instead of 8. But the FPU stack still has 8 entries to encode and there are also still only has 8 MMX registers in 64 bit mode (they overlay the FPU stack as you surely know). On the other hand with AVX-512 there will be 32 xmm/ymm/zmm registers available instead of 8 in 32 bit mode (4 times). UPDATE: On the other hand in 64 bit mode there are only 2 segment registers available instead of 6 in 32 bit mode (OK, the 4 common ones were (IMHO unjustifiably, since there are some cool things that you can use them for if you know what you do) not used in modern 32 bit OSes (Windows NT, Linux), so they were left out). TLDR: The multitude depends on the type of register that you consider.
  - hrydgard 10y ago
    The FPU stack is only 8 entries in x86-64, yes, but the 128-bit SSE float/SIMD register set was indeed expanded to 16 entries, just like the GPRs (rax, rcx etc). The FPU stack is legacy and is barely used anymore, instead most floating point operations are done with SSE instructions.
    - wolfgke 10y ago
      > The FPU stack is legacy and is barely used anymore I know that if you implement an algorithm via SSE/AVX it typically is much faster than if you use the FPU. But I still believe that the FPU has its uses: For example it also supports 80 bit precision floating point numbers, while SSE/AVX only support 32 or 64 bit ones. There are applications where this capability can be quite useful. This is one reason why the FPU is still supported (and sometimes used) in 64 bit mode.
microcolonel 10y ago
Turns out most programs don't really need that much register space. Some do, though, really depends on what you're running.

ygra 10y ago

Rico responded to that question on one Reddit discussion about the issue once: https://www.reddit.com/r/programming/comments/3zddyh/revisiting_64bitness_in_visual_studio_and/cylewoo/?context=3 https://www.reddit.com/r/programming/comments/3zddyh/revisit... In short, due to VS having an already large working set it hurts more to let it grow even larger than having more registers helps. I also think that many people took his stance as »32 bit should enough for anybody and no one should move to 64 bit«, whereas it was more a »performance characteristics for different types of applications are very different and for Visual Studio it's a choice that will make things slower«. Admittedly, that doesn't appease the people who experience crashes, although extensions like ReSharper are often more wasteful with memory than the IDE itself and those could just as easy be put in a separate process. Although for JetBrains it's probably a marketing argument to push ReSharper users to Rider (which actually uses an out-of-process model and thus not have the problem).

scott_s 10y ago
Like other people, I remain unconvinced by his arguments. The main problem is that no one can say for certain what will actually happen, as the 64-bit version does not exist. I also care about performance (for a living!) and I've been humbled enough times by "for sure this is what will happen" type thinking that I know it's just too hard to predict with certainty what will happen with such a complex interaction of parts. Specifically, I'm skeptical of the argument that more registers will not help, but no one can test the arguments empirically. Which is always dangerous ground. I do, however, buy people's arguments that they are feeling real pain by the memory limitations. Even if 32-bit is faster at the moment, I think it's a short-sighted decision to not port to 64-bit. First, the memory issue that everyone has brought up. Two, I find it likely that over time, using the now-standard bitedness (I know that's not a word, forgive me, I have a cold and mind is foggy) will yield benefits because it's the common path in the processor. (ygra, I know you're not necessarily in agreement with everything Rico said, so I'm not really arguing with you.)

masklinn 10y ago

> I might be wrong, but aren't there much more registers available in 64 bit mode on intel? It's not "intel", it's x86. x86_64 has twice the number of registers.

digi_owl 10y ago
Never mind that it was AMD that extended x86 to support 64 bit, while Intel was off chasing its own tail with Itanium.
wolfgke 10y ago
> x86_64 has twice the number of registers The "typical ALU instructions" as add, cmp etc. can now encode 16 registers instead of 8. But the FPU stack still has 8 entries to encode and there are also still only has 8 MMX registers in 64 bit mode (they overlay the FPU stack as you surely know). On the other hand with AVX-512 there will be 32 xmm/ymm/zmm registers available instead of 8 in 32 bit mode (4 times). UPDATE: On the other hand in 64 bit mode there are only 2 segment registers available instead of 6 in 32 bit mode (OK, the 4 common ones were (IMHO unjustifiably, since there are some cool things that you can use them for if you know what you do) not used in modern 32 bit OSes (Windows NT, Linux), so they were left out). TLDR: The multitude depends on the type of register that you consider.
- hrydgard 10y ago
  The FPU stack is only 8 entries in x86-64, yes, but the 128-bit SSE float/SIMD register set was indeed expanded to 16 entries, just like the GPRs (rax, rcx etc). The FPU stack is legacy and is barely used anymore, instead most floating point operations are done with SSE instructions.
  - wolfgke 10y ago
    > The FPU stack is legacy and is barely used anymore I know that if you implement an algorithm via SSE/AVX it typically is much faster than if you use the FPU. But I still believe that the FPU has its uses: For example it also supports 80 bit precision floating point numbers, while SSE/AVX only support 32 or 64 bit ones. There are applications where this capability can be quite useful. This is one reason why the FPU is still supported (and sometimes used) in 64 bit mode.

microcolonel 10y ago

Turns out most programs don't really need that much register space. Some do, though, really depends on what you're running.