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.
We don't want to do the work.
32 bits ought to be enough for anyone.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
The day they broke that limit, some cheered. Others looked upon it with dread, knowing the hellspawn that would follow.
"and we have a really, really lame explanation for our underlying laziness and/or incompetence"
"also, fuck you, developers."
I've fallen off your lawn, and I can't get up.
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.
I have a quad core 3.5Ghz with 32GB of RAM, VS2015 installed on an SSD. It takes over 15 seconds to get to a working state. After the last update (2), then the Update patch, it now pops up some idiotic error about scc something-or-other every time it starts, and every time I open a project. An update for this POS software takes at least 15 minutes -- with far and away most of the time spent sitting at 99% complete with the status message: "Visual Studio is configuring itself -- this might take a while."
Yeah no shit it might take a while.
In summary Visual Studio has become one of the worst programs I use. It is horrifically bad in all aspects: Hard to use, impossible to navigate, useless documentation.
When I wander over to the C++ forums on reddit I frequently see their runtime library/compiler guy -- I think his name is STL, sheepishly saying what an antiquated POS their C++ compiler is. That doesn't give me warm fuzzy feelings either.
It's all just more nails in the coffin as far as I'm concerned. I rarely develop for Windows anymore and when I have to it's because I'm forced to. The entire Windows platform is a complete disaster from a developer's point of view. All the years of MSDN trying to sell whatever the current darling language, what's-old-is-new-again (C++ is back, did you notice?), terrible, TERRIBLE API design, and just general CRUFT (did I mention that COM is back too..?) have finally caught up to them.
No 64 bit version "because not needed" on Linux meanwhile you have to install 64 multilib packages and compile from source many of those on ArchLinux just to run Steam. Come on guys, you can argue that staying 32 bit is smaller but then it actually becomes larger because you have to install tons more 32bit libraries to support legacy on our all shiny 64 bit systems. In effect it is smaller and leaner to go all 64 bit.
is and has always been a disgusting kludge on top of the 32-bit (that they finally managed to get in decent shape). Faced with the necessity to build something just as ugly for another product, I'm not sure I would have reacted differently than they did.
Oh, and the bit about valuing the feedback is priceless, of course.
I can assure you, the best way to get rid of dragons is to have one of your own.
Microsoft makes very good developer tools - but the decision on how to make them, unfortunately, has constantly been shaped by a LONG series of internal political decisions on what products they want to be promoting at that very second.
DirectX, Crystal Reports, 'Modern' (metro to everyone else), the dot Net framework, phones, MS-specific java,, etc., etc... Some of them ended up good ideas, some of them were just what they wanted to push to capture some market. It's a big part of why it's actually something of a bad idea to just read Microsoft documentation on their own products - they'll tend to color every piece of introductory material in light of what they want to promote at that moment, what they want YOU to do for THEM.
They also tend to stall on some technologies that they feel will shift resources in a way that won't help them at that very moment. Shifting to 64-bit developer tools might be a bit expensive to test binary interoperability with everything - and Microsoft also hasn't found a very good consistent method of hosting 32-bit DLLs into 64-bit executables that isn't just some piped communication between different process spaces. I can understand their reluctance to commit resources into something they're not sure they can make work seamlessly.
But really, I've seen a lot of my Visual Studio exe memory usage stats floating up to the large-address-aware 32-bit limit. Even if it doesn't meet 100% compatibility/interoperability, I think it would still be a good idea to start an experimental option of a set of 64-bit build environments. Perhaps with embedded 32-bit memory spaces that you can host stuff in without loading errors, if at all possible - but 64-bit-only restrictions if that's not possible would also be acceptable.
Ryan Fenton
Damn right, any project this big should be done with professional tools!
Glad MS finally admits it.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
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.
With a very few specific possible exceptions, x64 code is indisputably faster than x86. The reduction in register pressure buys you a speed increase of about 10% in my experience.
The code is somewhat larger, of course, but instruction caches have also grown in size since this was observed to be an issue.
Meanwhile, recompiling correctly-written C++ code to target x64 amounts to changing a couple of flags in the build script, so laziness is no real excuse.
Sure that would mean using more memory?
Of course. But it also means being able to employ more memory.
The math works like this, roughly: going to 64 bits can increase the memory needed by a factor of up to 2^1. At the same time it expands your memory space by 2^32. So that project that the IDE was thrashing on because the projected needed 5 GB of RAM may need 10 GB o RAM after the IDE is migrated to 64 bit. But that's fine because a basic developer's machine has 16GB of RAM these days. The problem was that you couldn't make use of it.
I'm old enough to have gone through this three times: once going from eight to sixteen bit; next from sixteen to thirty two and then finally thirty-two to sixty-four. I think it's pretty safe to say that I won't ever have to go through another power-of-two word size shift though:) .
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
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 immediate reaction is to say it is silly that they are not offering a 64-bit version.
But many developers are likely using a number of extensions - which will currently be 32-bit because that's what Visual Studio is, and 64-bit would require all the extensions provide new versions as well.
It probably wouldn't take a huge effort to offer Visual Studio as both 32-bit and 64-bit versions (just like Office). But a more useful - although much longer - use of engineering effort would be to take the full Visual Studio experience on to the CLR.
GCC and LLVM are not IDEs. So your comment actually has fuck-all to do with the story.
Sure that would mean using more memory?
Yes, but how much depends on the application. I haven't found a good scholarly reference on average memory use increase for 64 bit applications, however some rough worst-case scenarios I've found see to indicate a 20% memory increase is considered to be at the high end. Most applications will see much less of an increase.
On the flip side, 64 applications get a lot more registers available to them in x86_64 mode -- eight additional General Purpose Registers. Thus, a compiler can better optimize applications to squeeze more performance out of the processor, by loading more data into registers (or potentially by not having to swap data in and out of registers as frequently as in 32 bit mode).
Most consider this a good trade off. Extra RAM is easy to come by when compared to extra processing speed.
Yaz
Honestly, I live at the CLI and only use the IDE when I need to debug something, so I couldn't say if it would actually be worthwhile to recompile it for x64 or not. It's not true that there is no performance benefit in doing so, but I agree that it's far from clear that anyone would notice or care.
The compiler itself (cl.exe) is already built as an x64 executable according to dumpbin, even though it still resides in the legacy c:\program files (x86) folder. That's where the performance really matters.
If .NET has been abandoned, what's the replacement? Why have they completely rewritten software they're going to abandon. What's this? You really don't know what you're talking about. Ever since Silverlight was abandoned, people like you keep posting this shit about .NET being dead and yet Microsoft keep releasing new versions and making you look like fools.
Competition is a good thing. Once they come out with an IDE for .NET (Project Rider), Microsoft will finally have some real competition in the IDE space. THAT might well be what Microsoft need to help it decide to put in the effort to make a 64-bit version.