Slashdot Mirror
Microsoft Declines To Make a 64-Bit Visual Studio (uservoice.com)
OhPlz writes: A request was made back in 2011 for Microsoft to provide a 64 bit version of Visual Studio to address out-of-memory issues. After sitting on the request for all that time, Microsoft is now declining it, stating that it would not be good for performance.
After almost five years, the request received 3,127 votes on the UserVoice forum for Visual Studio. Microsoft instead recommended the vsFunnel extension to optimize memory by filtering low-priority projects, adding "we highly value your feedback." They cited a December MSDN post that had argued "smaller is faster," and that no performance benefits would be realized for users whose code and data already fit into a 32-bit address space, while most other issues could be addressed with better data design.
After almost five years, the request received 3,127 votes on the UserVoice forum for Visual Studio. Microsoft instead recommended the vsFunnel extension to optimize memory by filtering low-priority projects, adding "we highly value your feedback." They cited a December MSDN post that had argued "smaller is faster," and that no performance benefits would be realized for users whose code and data already fit into a 32-bit address space, while most other issues could be addressed with better data design.
The real problem is that the fancy built-in designers, such as the WPF designer, only work with 32-bit components in 32-bit Visual Studio. When someone writes a component that is 64-bit, because it references a DLL that in-turn references, say, a 64-bit Oracle driver, which is part of code that we don't have control over. Now the designer won't load and shows a cryptic error message.
Microsoft develops software the same way the British Army fought the Somme Offensive. They use massive amounts of cheap programmers, and just pound away until they have something to release. The code quality is so poor that they often just throw it way and do a complete rewrite for the next version. You may think that supporting 64 bit would mean just changing a few header files, tweaking some compiler flags, and typing "make world", but it would not be that simple. The code is likely riddled throughout with obscure 32 bit dependencies, and would require a huge and expensive effort to fix.
http://store.steampowered.com/... Less than 7-8% total using 32-bit systems to run Steam. Games need to catch up to 64-bit land. It is a good/valid point that you need the libraries to run the games but that is slightly different than having to install them just to start Steam. It's also arguing towards the negative not the positive.. Mobile is going 64 bit also and I doubt it will remain very 32 bit compatible.
The big problem is debugging.
We've got a 64-bit app which VS will happily build and the app runs fine. But if we want to debug it live VS chokes, falls over and dies, out of memory once the app uses more than 3 GB.
It's legit using > 4GB because it's heavy image processing of large color images at high dpi and the machines are specced for it. Obviously, we could page stuff in and out of memory ourselves, but that rather defeats the purpose of 64-bit OS and would slow everything down (speed is paramount here, burning memory to get it was a primary design decision) - and the program runs fine when not debugging in VS.
I worked at MS in early 00s. We didn't use VS to write code. We used a stripped down version of VS or even WinDbg to debug. Nowadays I use Vim and YouCompleteMe (on Linux) and it just works. Zero dollars, easy to set up.
The code quality is so poor that they often just throw it way and do a complete rewrite for the next version.
Based on what? For the most part when MS projects have either had source code leaked or made open source the analysis of the code has shown some pretty fine programming. Re-writes seem to be based on strategic decisions and also decisions to not end up with endless layers upon layers of cruft (something that also supports code quality in a positive way).
They should do something like oh I dont know 'recompile it as 64 bit' and PROVE IT and show their work?!
I don't have to see the compilation to understand that it is going to be slower: I can read processor spec sheets. All modern processors can do 32 bit pointer arithmetic in a single instruction. This is critical because pointer math is highly linear in nature and *will cause pipeline stalls*. 64 bit arithmetic by contrast is typically several cycles long, and will commonly stall the pipeline. The performance hit I have commonly heard is 10%, and seems to come from some amount of informal testing.
Take a look at this for an idea of some of the testing that gets done on these kinds of things.
I wish I had a good sig, but all the good ones are copyrighted