5 ms·

Not moving to 64 bit has been a pragmatic decision [1]. As for crashing, I used it for over 10 years at my previous company and it never crashed once. At my cur

Not moving to 64 bit has been a pragmatic decision [1]. As for crashing, I used it for over 10 years at my previous company and it never crashed once. At my current company it only crashes when I am using the Stylevision plug-in, which is really, really, buggy. [1] http://blogs.msdn.com/b/ricom/archive/2009/06/10/visual-studio-why-is-there-no-64-bit-version.aspx http://blogs.msdn.com/b/ricom/archive/2009/06/10/visual-stud...

criddell 11y ago
That pragmatic decision was made 7 years ago. A lot has changed since then and I don't think the arguments hold up. What developer machine doesn't have at least 16 GB of RAM these days?
- gelasio 11y ago
  Did you even read the article? The arguments still hold up. It's clearly the case that it's not worth the effort to move VS to 64-bit. - "First, from a performance perspective the pointers get larger, so data structures get larger, and the processor cache stays the same size. That basically results in a raw speed hit..." - "The cost of a full port [due to the amount of code involved, not the quality of the code] of that much native code is going to be quite high and of course all known extensions would break and we’d basically have to create a 64 bit ecosystem pretty much like you do for drivers. Ouch." - "A 64 bit address space for the process isn’t going to help you with page faults except in maybe indirect ways, and it will definitely hurt you in direct ways because your data is bigger...32 bit processes accrue all these benefits just as surely as 64 bit ones."
- sblom 11y ago
  And they have current benchmarks that indicate that it's still the right decision: http://blogs.msdn.com/b/ricom/archive/2015/12/29/revisiting-64-bit-ness-in-visual-studio-and-elsewhere.aspx http://blogs.msdn.com/b/ricom/archive/2015/12/29/revisiting-...
  - criddell 11y ago
    Thanks for posting that (although I didn't see any benchmarks). My big problem with the first article was that in my experience, the extra registers available in 64-bit make all the difference in the world. In the comments for the article you posted, he says that isn't true with VS. Surprising, but I'll take his word for it. Still, it bothers me that he keeps talking about 4 GB of code and data should be enough. VS becomes pretty unusable for me around 1.5 - 2 GB. If it worked reliably up to the 4 GB limit, I'd be happier.
    - ygra 11y ago
      The limit is usually address space fragmentation and at one point not being able to find a piece of memory large enough for an allocation. Depending on the allocation patterns this may happen around 3 GiB but for some applications even around 1.7 GiB already. VS gets unbearably slow around 2 GiB memory, though, most likely because the native allocator has to piece together all free pieces of memory again and in the managed part the GC probably has fun trying to compact memory.
- colejohnson66 11y ago
  Me. I'm still rocking 4 gigs.

criddell 11y ago

That pragmatic decision was made 7 years ago. A lot has changed since then and I don't think the arguments hold up. What developer machine doesn't have at least 16 GB of RAM these days?

gelasio 11y ago
Did you even read the article? The arguments still hold up. It's clearly the case that it's not worth the effort to move VS to 64-bit. - "First, from a performance perspective the pointers get larger, so data structures get larger, and the processor cache stays the same size. That basically results in a raw speed hit..." - "The cost of a full port [due to the amount of code involved, not the quality of the code] of that much native code is going to be quite high and of course all known extensions would break and we’d basically have to create a 64 bit ecosystem pretty much like you do for drivers. Ouch." - "A 64 bit address space for the process isn’t going to help you with page faults except in maybe indirect ways, and it will definitely hurt you in direct ways because your data is bigger...32 bit processes accrue all these benefits just as surely as 64 bit ones."
sblom 11y ago
And they have current benchmarks that indicate that it's still the right decision: http://blogs.msdn.com/b/ricom/archive/2015/12/29/revisiting-64-bit-ness-in-visual-studio-and-elsewhere.aspx http://blogs.msdn.com/b/ricom/archive/2015/12/29/revisiting-...
- criddell 11y ago
  Thanks for posting that (although I didn't see any benchmarks). My big problem with the first article was that in my experience, the extra registers available in 64-bit make all the difference in the world. In the comments for the article you posted, he says that isn't true with VS. Surprising, but I'll take his word for it. Still, it bothers me that he keeps talking about 4 GB of code and data should be enough. VS becomes pretty unusable for me around 1.5 - 2 GB. If it worked reliably up to the 4 GB limit, I'd be happier.
  - ygra 11y ago
    The limit is usually address space fragmentation and at one point not being able to find a piece of memory large enough for an allocation. Depending on the allocation patterns this may happen around 3 GiB but for some applications even around 1.7 GiB already. VS gets unbearably slow around 2 GiB memory, though, most likely because the native allocator has to piece together all free pieces of memory again and in the managed part the GC probably has fun trying to compact memory.
colejohnson66 11y ago
Me. I'm still rocking 4 gigs.