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.

Comments

In other words...

[ChodaBoyUSA]

We don't want to do the work.

Re: In other words...

[Anonymous Coward]

It's not about doing the work, it's the outsourced Indian team doesn't know how to do the work.

Re: In other words...

[slack_justyb]

That's exactly how I read it. All the excuses giving are weak at best. Microsoft doesn't want to invest the time and money. But figures, Microsoft's products that are non-office are mostly turning into trash.

Re: In other words...

[Austerity Empowers]

It's not about doing the work, it's the outsourced Indian team doesn't know how to do the work.

I am pretty sure this is the actual reason, not just cynicism. MS has fired or encouraged significant attrition amongst it's can-do types, focusing those few who remain and who know how to do things into certain areas. The rest...they've backfilled with H1B or outright offshoring. Any other company would have collapsed by now, but monopolies are a powerful thing.

Re: In other words...

[justthinkit]

Microsoft is pushing purchasable apps in Windows 10. It has created a (crappy) new interface, so programs stupid enough to comply with the new interface must be written for it before they can be sold to everyone.

So Microsoft wants a head start -- "Sorry, our compiler is not available (to those outside Microsoft)". A couple of years from now, with the apps market saturdated, and Microsoft dominating once again in familiar (and new) categories, "Will you look at that, we WILL be shipping VS64. Here you go, one buggy VS64 beta coming up."

Re: In other words...

[AReilly]

a) 64 bit processors can do 64-bit arithmetic in a single cycle.
b) The 64-bit processors in question have more named registers (fewer stack spills), and a significantly more efficient function calling convention (ABI)
c) 64-bit ABI doesn't touch the old x87 register set, which is another net performance win. (Not that VS2015 will use this much.)
Ergo: most of the time they are faster.
The only way to make a 64-bit program slower than a 32-bit one is to have enough pointer-chasing and associated irregular dynamic data that the change in pointer size materially affects the data cache miss rate. Certainly there is some code like that: VS2015 might even be an example.

How fast do you need your IDE to be though, and how much is performance really the instruction set's fault? Versions of Visual Studio have been produced that run in everything from .NET to JavaScript, and that's fair because most of the cycles are going to be consumed in GUI and file stacks anyway. Native code performance is hardly going to be the issue.

The issue is almost certainly that LLP64 is a dumb idea, and the code base will have lots and lots of pieces of historical code that assume that you can manipulate pointers with long arithmetic, and all of those are going to have to be found and fixed by hand, often involving real understanding and design decisions.

32-bit visual studio

[fyngyrz]

"and we have a really, really lame explanation for our underlying laziness and/or incompetence"

"also, fuck you, developers."

Re:32-bit visual studio

[Anonymous Coward]

I did a couple of 64-bit ports in the past and that's pretty much what it took. The first application was about 50000 lines of code that I had worked on for about a year, i.e., I didn't write it, but I fixed it and refactored it. That conversion took about 2 days, and most of that was making small fixes because the header files were reorganized between gcc 3 and gcc 4.

The second time I did it was for a code base of about 2 million lines of code that I did not "own" in the same way. That took about three weeks, plus about another week from another developer. This was not code that had been developed in a well-disciplined way, but it worked, and the conversion ended up being very successful and took a lot less time than management had expected.

Re:32-bit visual studio

[Fragnet]

I've been a developer for 15 years and I can say Visual Studio environment is way better than anything available on Linux. The code dependencies can be resolved in 64 bit but Microsoft is a business and there's an opportunity cost associated with doing that rather than something else more people actually need.

Re: 32-bit visual studio

[Malc]

I bet their compiler catches most of the bad shit that only works on 32-bit builds... But they have so many warnings they can't see this.

Re:32-bit visual studio

[maugle]

I'm sure Visual Studio works quite well for you. But, to counter one anecdote with another, I found Visual Studio to be lackluster and irritating in a thousand little ways, and its marginally-better code completion isn't enough to make me prefer it over either Eclipse or QT Creator.

As for a 64-bit Visual Studio, my guess is that the code problems of porting to 64-bit are dwarfed by the bureaucratic maze involved in releasing a new edition of a product.

Re:32-bit visual studio

[MachineShedFred]

It would probably suck worse, because the memory leaks and plug-in bloat would be only bound by physical memory, rather than the enforced 32-bit memory space.

If Microsoft is telling people that they should just write better code in order to stay inside of a 32-bit boundary, they should start practicing what they preach and lead by example.

visual studio

[Anonymous Coward]

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.

Re:visual studio

[Dutch Gun]

I've been using VS 2015 since it was released, and using VS professionally for close to 20 years. The quality of VS and the compiler has waxed and waned over the years, but I'm pretty happy with the way the current version is looking, given the general responsiveness, functionality, and stability of the IDE and the C++ compiler itself. It has pretty close to full C++ 14 compliance at this point - and certainly has the features *I* care about. If you're seeing such poor performance and odd error messages, there's something strange going on, as that's not a typical experience. My machine is rather *less* powerful than yours, and I just counted - it takes six second to get VS up and running for me.

Stephan T Lavavej is the maintainer you're thinking of, and he maintains the standard C++ library, so it's pretty awesome his initials are STL. He's one of the few MS devs that interacts regularly with developers and speaks candidly about MS's development, and has given some pretty interesting talks. True, the MS C++ compiler is quite old, but they've been modernizing it in light of C++'s renewed interest and features, with pretty decent results (if slower than many wish, probably including STL). GCC is also quite old, if you recall, but software can be updated. Clang is the only "new" C++ compiler in widespread use I'm aware of, so it obviously benefits from a more modern implementation, having lessons learned applied during initial development.

And COM never really went away (very few things in Windows do), but it's claim to fame was interprocess-communication and a language-independent execution model. New libraries have superseded the former, and .NET has largely replaced the latter. I'm not sure what constitutes "is back", but I've not heard anyone talking about it, and certainly nothing *new*. Maybe you're just hearing more about what's always been there since natively compiled code is making something of a minor comeback, with interpreted code like .NET never really having met promised performance expectations, even when JIT-compiled.

As for 64-bit Visual Studio, it's strange that they're not looking more seriously at this, but my guess is they ran into some severe technical hurdles in early efforts to port it, so are downplaying the importance. I mean, who doesn't develop on 64-bit machines at this point? I'll bet they're working on it internally, but are not ready to commit to anything.

64-bit Windows

[Yurka]

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.

This'll change...

[RyanFenton]

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

The good news is...

[Gravis Zero]

GCC and LLVM have full 64-bit capabilities and are free.

Re:Summary :

[lgw]

It was not stupid at all in the domain for which is was invented. Simonyi (the eponymous Hungarian) was apparently appalled at what it became.

The original idea was to decorate objects of the same type, but different semantics, so that you wouldn't confuse them: specifically rows and columns int the Excel codebase. You could tell instantly that rwFoo - coBar was a bug, even though they were both ints and the compiler was fine with it. It's a fundamental weakness of C and C++ through today that's there's no way to make efficient, disjoint integral types.

It can also be useful to distinguish between types that typedef to the same type on one platform, but might typedef to different types on another, but IMO it's not worth the clutter.