12 ms·

Revisiting 64-bit-ness in Visual Studio and elsewhere (2015)

120 points by svenfaw 10y ago

davrosthedalek 10y ago
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.
nailer 10y ago
> In the immortal words of Sherman T. Potter: “Horse hucky!” ?
- wolfgke 10y ago
  Sherman T. Potter > http://mash.wikia.com/wiki/Sherman_T._Potter http://mash.wikia.com/wiki/Sherman_T._Potter horse huckey: > http://www.urbandictionary.com/define.php?term=horse%20hockey http://www.urbandictionary.com/define.php?term=horse%20hocke... Colonel Potter curses (“Horse hucky!” is at the beginning): > https://www.youtube.com/watch?v=vhagzSEXzic https://www.youtube.com/watch?v=vhagzSEXzic
mtdewcmu 10y ago
I only have VS2010, but I always felt that VS stacked up pretty well against the competition, performance-wise. Eclipse always seemed painfully slow, and Xcode hasn't really impressed with its performance. That's no reason to rest on your laurels, surely. But at least VS shows some evidence of restraint in abusing resources.
- taude 10y ago
  I agree for the most part. But Eclipse has gotten a bit better in the recent years. I'm mostly on Intelli-J now, but when I was forced into Eclipse for a project, I didn't completely cry.
- alkonaut 10y ago
  The big perf drop in VS was between 2013 and 2015 when Roslyn was introduced (not sure if that's the reason though). It has improved somewhat in 2017 but I still find 2013 to be significantly faster than 2017.
draw_down 10y ago
Hmm. We must all be a bunch of rubes for running 64-bit code in so many places these days.
- draw_down 10y ago
  The mob has spoken! 64-bit is actually good.
sherincall 10y ago
I really wish MSFT would support the x32 ABI[0]. While having a single amd64 ABI, compared to 6-7 active in the x86 days, has its advantages, MSFT already threw it away with vectorcall. And x32 is arguable more useful than vectorcall. [0]: https://en.wikipedia.org/wiki/X32_ABI https://en.wikipedia.org/wiki/X32_ABI
- wolfgke 10y ago
  An ABI for amd64 was consciously developed independently by the gcc developers and Microsoft. Microsoft did "the obvious thing" and extended __fastcall to define their ABI. Here are links about this topic: > http://stackoverflow.com/a/35619528/497193 http://stackoverflow.com/a/35619528/497193 > http://stackoverflow.com/a/4438515/497193 http://stackoverflow.com/a/4438515/497193 > http://stackoverflow.com/a/35621290/497193 http://stackoverflow.com/a/35621290/497193
- sp332 10y ago
  I already have 32-bit and 64-bit copies of all the libraries on my computer. I'm really not looking forward to having a third copy lying around.
- fsfod 10y ago
  There are some ugly hacks[0] to run 64 bit code in a 32 bit process on windows by using retf switch to 64 bit code segment with one of the major limitations being you can't load 64 dlls into the process. [0]: http://blog.rewolf.pl/blog/?p=102 http://blog.rewolf.pl/blog/?p=102
marktucker 10y ago
In my experience, Visual Studio performance has improved significantly since VS2010, but if you compare it to VC6, it's a joke. There's still an old PC at the office running it, and double clicking a project opens the IDE and loads the project in less than a second. It's beautiful.
- roel_v 10y ago
  Sure, but it does so much more than VC6 used to do. I mean, the intellisense is so good nowadays, the continuous compiling that essentially gives you on the fly 'compiler errors', ... I agree that it would probably be nice if those could be turned off, and the UI is sluggish, but VC6 was (apart from being fast) not much to write home about (compared to what we have now).
  - BinaryIdiot 10y ago
    To be fair though parent was referring to VC6's start-up time compared to the current version's start-up time. Is it fair to expect continuous compilation or maybe even intenseness to slow down start-up? I'm not so sure.
  - orcy 10y ago
    We still build some stuff with VS2005 and it feels very fast and responsive while having everything I usually need in ide. The only thing it missing is modern C++ compiler.
- whitefish 10y ago
  Couldn't you say this about the software industry in general? In the 90's I used to have a Sun workstation on my desk. It ran the powerful Solaris operating system, but had just 16MB of RAM! Today you need 1GB of RAM to run an OS comfortably. My question: what does modern Linux do that Solaris from the 90's did not, that it requires 50x more memory?
  - oblio 10y ago
    Well, I don't know, could your Solaris (mostly) seamlessly connect and disconnect to wireless networks? I don't even think there were that many wireless networks in the world back then :) Anyway, this is is just 1 contrived example of something modern OSs do, and that OSs from the 90's didn't do. Sure, there's some bloat, but a lot of it is the "Mozilla kind": "Mozilla is big not because it is full of useless crap. It is big because your needs are big".
taspeotis 10y ago
Run devenv /safemode to load the IDE without third party extensions (think ReSharper) and the thing flies. It's not Microsoft's code that's the problem.
- Splines 10y ago
  Yeah - my work instance of VS is sluggish as hell, and I sometimes load up a separate instance with toy problems to prototype ideas and it's practically as light as notepad.
- BinaryIdiot 10y ago
  We...may have different definitions of "flies". Yes if you disable third party plugins then it should be fast at various points in its lifecycle. At the same time it's not really that fast when you have zero plugins installed...
- alkonaut 10y ago
  This might be the case - but the IDE isn't really complete withiut extensions. I need svn integration, and I need basic refactoring from R# like "move type to new file". The problem is probably that memory is crowded and plugins must do a lot in-process via COM. If Microsoft really wanted to make VS fly for a lot of people they could just add the 10% most popular features from the 10most popular extensions. It would want nothing more than to throw out R#
oobey 10y ago
Would he have made those same comments to resist going from 16 to 32 bit? Hell, why not stick with 8 bit? We can just optimize everything to work on that, right?
- kazinator 10y ago
  More is always better. Four wheels is better than two; cars should have eight wheels. Look at GUID partition tables. With MBR, we had to hobble along with only a byte to identify partition types. Now we have 128 bits. We can finally support more filesystem kinds now than there are atoms in the Sun, all in one system installation, and the bootloader just has to look at the GUID. A 32 bit "fourcc" partition label clearly wouldn't have been enough.
  - XorNot 10y ago
    GUID partition tables mean we don't need to coordinate identifiers. That's the point.
    - kazinator 10y ago
      But in fact, we don't need to coordinate identifiers. Clashes in partition ID's are of no practical consequence. A 32 bit "fourCC" would be more than adequate. It could even be constrained just to readable characters, like LNXF (Linux Filesystem) and LNXS (Linux Swap). If another OS happens to use LNXF for something, and you have that OS in the same darn system, it doesn't matter. You just don't have that "foreign" LNXF in your /etc/fstab, and likewise it doesn't have the Linux ones in its equivalent of /etc/fstab. The only thing that needs a clash-free label is the EFI boot partition, so the boot firmware can unambiguously identify all these partitions on all attached devices and offer them as boot options.
      - XorNot 10y ago
        Why have them at all then? If the argument you want to make is that they are of no consequence, then you need to answer why your proposal of still doing something is warranted.
eb0la 10y ago
I remember people favoring the use of their 32bit JVM instead of the 64-bit one for performance reasons but didn't wondered why. Makes sense if you're running Java with -Xmx1024m
- loganmhb 10y ago
  When reading about Elasticsearch I was fascinated to learn that the JVM can often use 32-bit object pointers to address about 32GB of RAM when running in 64-bit mode: https://wiki.openjdk.java.net/display/HotSpot/CompressedOops https://wiki.openjdk.java.net/display/HotSpot/CompressedOops
  - will_hughes 10y ago
    As someone who comes from the .NET world, this is something that pissed me off about configuring Java applications like Elastic. If I've got a box with 512GB of ram, it seems I'm supposed to spin up multiple instances to satisfy this, all because the JVM has a hissy fit if you go over ~30GB. This then means worrying about replication and ensuring we don't have both the primary and replicas sitting on the same box. It seems insane that this is an actual issue in 2017.
    - wolfgke 10y ago
      > If I've got a box with 512GB of ram, it seems I'm supposed to spin up multiple instances to satisfy this, all because the JVM has a hissy fit if you go over ~30GB. What is the actual technical reason why the JVM cannot (easily?) address more than 32 GiB of RAM?
      - masklinn 10y ago
        I don't believe that's the case (an other commenter notes they run solr processes up to 160GB), however they may have run into the compressed oops optimisation, or more precisely the end of it: because Java is a very pointer-heavy language, if the maximum heap size is under 32GB many 64b JVMs use a variant of tagged pointers where they have 35 bit pointers stored in 32 bits (since the lower 3 bits are always empty they can shift them in/out). Except once you breach the 32GB limit, your 32 bit pointers grow to 64, and depending on your application you might need to grow your maximum heap into the high 40s to get room for new objects: https://blog.codecentric.de/en/2014/02/35gb-heap-less-32gb-java-jvm-memory-oddities/ https://blog.codecentric.de/en/2014/02/35gb-heap-less-32gb-j...
andrewvijay 10y ago
I only work on higher level languages like js and Python. Makes me realize how much I need to know about performance before I complain about IDEs.
BinaryIdiot 10y ago
I remember his original post back in 2009 and being very unsatisfied. I wanted the 64-bit transition only so I could properly use my tools at work (used to work in a .Net shop). We had resharper and several other plugins that ran in the same Visual Studio process as everything else and it was fairly common to hit the memory limit of a 32-bit process and Visual Studio would essentially die until it was killed and restarted. Sure, you can say "stop using those tools" or "they should have written them better". But at the time I was required to use most of them (it wasn't only Resharper though Resharper was pretty nice). Today I don't have this problem anymore. But I think because of that type of issue it would still likely be worth it. Honestly I feel like they could optimize Visual Studio at the same time; it has a ton of capability but it's also incredibly large and, from my understanding, carries a TON of legacy code and resources throughout.
- ygra 10y ago
  I guess his original point was that while moving to 64 bit would help the few users who actually hit memory allocation limits, it would also be a monumental effort for a project the size of Visual Studio to do so, including out-of-process support for 32-bit extensions to maintain compatibility, probably rethinking designers and debugging along the way. And all that to make things actually slower and taking more memory for everyone. His argument wasn't entirely »Stop using those tools while we do nothing at all«. It was »They should have done the right thing, but we'll also work towards making Visual Studio take less memory«. Especially considering that not leading everything you might eventually ever need at once in the beginning has probably a much smaller compatibility impact than upgrading significant parts of the IDE.
sp332 10y ago
Security can improve with 64-bit as well. It's a lot harder to break ASLR in a 64-bit address space than a 32-bit one. Though again, that might not apply to VS where a user can get "arbitrary code execution" by design.
- Cyph0n 10y ago
  That's assuming high entropy for address randomization of course. A 64-bit OS that has a weak ASLR implementation could end up weaker than a 32-bit OS that implements ASLR correctly. Your point definitely stands if both are well made.
- rrdharan 10y ago
  You might still care about security properties/exploits in Visual Studio given that a lot of use cases involve running it as Administrator: https://tomssl.com/2015/03/31/always-run-visual-studio-as-administrator-with-no-uac-prompt/ https://tomssl.com/2015/03/31/always-run-visual-studio-as-ad... I mean realistically don't know how much of a concern this is, but it's conceivable you might be running Visual Studio with elevated permissions on a shared machine and in turn want the ASLR protections.
snnn 10y ago
Right now, I'm fighting with: "fatal error LNK1248: image size (1004CB720) exceeds maximum allowable size (FFFFFFFF)" :-(
- ygra 10y ago
  That has nothing to do with Visual Studio, though. There is a 64-bit linker and you can use it.
  - snnn 10y ago
    I already set toolset to x64. It's 64 bits cl.exe running.
- mrich 10y ago
  You will have to split up your library. There is also a limit for PDB files of 1GB, which can be workarounded to 2GB, but from the error above I think you are not hitting this limit.
  - snnn 10y ago
    Thanks for your help.
to3m 10y ago
"Any packages that really need that much memory could be built in their own 64-bit process and seamlessly integrated into VS" Wait... did you just tell me to go fuck myself? ;)
- recursive 10y ago
  I believe he did, Bob.
codeflo 10y ago
At work, I have a fast machine with 32 GB of RAM, of which Visual Studio can only access about 3 GB. About once a month, Visual Studio crashes with some kind of out-of-memory error, and more often than that, it slows down to a crawl because it has to garbage collect every few seconds in an attempt to keep its memory usage below this magic limit. Even though the machine has 20 GB of free RAM that Visual Studio just can't use. The author acknowledges that this can happen: > So, you’re now out of address space. There are two ways you could try to address this. > a) Think carefully about your data representation and encode it in a more compact fashion > b) Allow the program to just use more memory > I’m the performance guy so of course I’m going to recommend that first option. As a "performance guy", he should know that using a bit more RAM is essentially free, and much, much easier to code than doing the kind of bit-fiddling wizardry he suggests ("encode it in a more compact fashion"). In practice, that kind of low-level code will not get written anyway, at least not by modern Microsoft, and much less so by most extension authors. Which means that there's an arbitrary and very hard limit on how much you can customize/extend Visual Studio before you hit that 3 GB wall. And again, this is on modern workstation machines with gigabytes of unused RAM lying around. In short, there may be very valid technical reasons why VS can't go 64-bit, but to claim that this doesn't hurt the product is in my opinion not justified.
- bicubic 10y ago
  Considering the 64 bit support problem has been going on for over five years now and the magical 3GB limit is increasingly absurd on modern hardware, I wonder if they've considered just giving up on VS and doubling down on VS Code. It also sorts out their desperate need for a UI overhaul.
  - brynjolf 10y ago
    Visual Studio Code is slow in comparison to VS. It has way less features. I hope this is not the path they take.
    - chillee 10y ago
      It's not slower than VS. It's just not an IDE.
SadWebDeveloper 10y ago
tl;dr... its humongous task and we are busy adding more "instant azure buying-options aka deployment tools", it will only benefit 1% of our users and we also want to keep milking this cow until the shit hit the fan.
kabdib 10y ago
This is a pretty myopic view of performance and 32-bit code. - You really only get 3GB of RAM - Actually, you get less than that, because of DLLs that get loaded into that space. - Actually actually, fragmentation becomes a problem, and making very good use of the remaining memory gets awkward pretty quickly. 3GB is pretty crowded, especially when you're talking about (say) a game with tens of GB of footprint. You need to page stuff into that footprint, and be clever about the memory pressure not affecting the user experience. On the server side of things, we regularly run processes with > 8GB footprints, including things like solr (at 32 to 160GB). Breaking this stuff up would involve a lot more disk and network chatter, as well as bugs involving OOM conditions, reducing global performance and reliability. So while VS may be fine with 32-bit code+data (I am not convinced), real-world applications definitely need more. I'm guessing that making a 64-bit VS is hard for legacy reasons, and that the 32-bit space is actually holding the VS team back (and possibly plugin makers as well).
- masklinn 10y ago
  > So while VS may be fine with 32-bit code+data (I am not convinced) Many people in this thread and the corresponding one on reddit report VS regularly crashing on OOM or eating all the CPU garbage-collecting nonstop as it gets closer and closer to the limit.
aussie123 10y ago
The author seems to be defensive, trying to justify the status quo. I would be interested what the real reasons are. Why have most other Microsoft products moved to 64bit but VS was hesitant from the beginning?
blauditore 10y ago
Disclaimer: I don't know too much about this field Can someone explain why exactly 64-bit is generally slower than 32-bit? I understand that more RAM will be used and I/O to it slowed down due to double the bits pushed around since "chunks" have double the length, which ends up being a lot of empty padding (is that correct?). But everything inside the CPU, like registers or ALUs, are 64 bits wide anyway (right?), so computing in 64-bit mode would just make use of resources that were unoccupied in 32-bit mode. Or am I missing something?
- jcranmer 10y ago
  The primary resource that's going to be hit is the cache. You get 8MB of cache whether you're in 32-bit mode or 64-bit mode. Switching to 64-bit mode means that you have half as much cache in terms of number of pointer fields you can store. Note this can also impact alignment of fields within structs--if you're on 64-bit, you want your pointers to appear before 32-bit fields; if you alternate, you waste a lot of extra space.
  - deleted 10y ago
    [deleted]
- vvanders 10y ago
  Cache sizes are fixed to less things fit in L1/L2 than did before.
- robert_foss 10y ago
  Because addresses are longer they will take up more space, which will lead to your CPUs instruction-cache (I-Cache) being more full, which directly translates into performance losses due to needed things being evicted from I-Cache. The same is true for L1/L2/L3 caches too. The same is true to a much lesser extent for taking up more space in ram, and to an even lesser extent for reading things from storage.
  - tigershark 10y ago
    This is true for non x86 architectures. Translating an x86 software to x64 brings performance benefits most of the times because of the ability to use the additional registers non accessible in x86 mode.
rikkus 10y ago
When I'm working on performance, I measure twice and cut once. I know measuring is 'hard' as there's a lot of code optimised for x86 in VS, but saying 'It would be slower built for 64 bit' is cutting before measuring even once. I have the greatest of respect for the author, but everyone needs to be exposed to 'trust, but verify' at least occasionally, just in case they happen to be wrong this once.
tpolm 10y ago
"The one who wants - seeks ways, who does not want - seeks a reason"
- TillE 10y ago
  That's pretty apt. There are always legitimate reasons why doing something is difficult and imperfect, but there's a really clear future here. It's absurd to think that Visual Studio will remain 32-bit in 10 or 20 years' time. And no, as any C++ developer will tell you, the answer is not to move to a souped-up text editor (Visual Studio Code).
tpolm 10y ago
"The one who wants - seeks ways, who does not want - seeks a reason"
tpolm 10y ago
2016 follow-up from the same "I regret I did this" person https://blogs.msdn.microsoft.com/ricom/2016/01/04/64-bit-visual-studio-the-pro-64-argument/ https://blogs.msdn.microsoft.com/ricom/2016/01/04/64-bit-vis...
moogly 10y ago
I don't see the point of this article. The VS team has moved more and more stuff out-of-process. VS 2015 can easily use more than 4 GB (if you're working in medium to large solutions), but it's divided up across 3-4 main processes. MSBuild processes (normally 1 per thread) are also staying around for 15 minutes now, so they can be reused.
- slededit 10y ago
  Where it falls down is if the debugger tries to load more than 3GB of symbols. Guaranteed crash every single time. You can manually limit the symbols it loads - but that doesn't apply to other parts like the profiler which will still crash deterministically.
gwern 10y ago
"Because virtually invariably the reason that programs are running out of memory is that they have chosen a strategy that requires huge amounts of data to be resident in order for them to work properly. Most of the time this is a fundamentally poor choice in the first place. Remember good locality gives you speed and big data structures are slow. They were slow even when they fit in memory, because less of them fits in cache. They aren’t getting any faster by getting bigger, they’re getting slower. Good data design includes affordances for the kinds of searches/updates that have to be done and makes it so that in general only a tiny fraction of the data actually needs to be resident to perform those operations. This happens all the time in basically every scalable system you ever encounter. Naturally I would want people to do this. ...In the VS space there are huge offenders. My favorite to complain about are the language services, which notoriously load huge amounts of data about my whole solution so as to provide Intellisense about a tiny fraction of it. That doesn’t seem to have changed since 2010." But I'm sure that by remaining 32-bit, in another 5 years maybe everyone will magically optimize their stuff... Any second now...
MrBuddyCasino 10y ago
The JVM has a neat trick where it uses 32 bit pointers up to 32GB heap sizes, because alignment is 8 bytes and so there are really only 1/8th distinct possible memory adresses for the whole adress space, so you can just easily map them. Is this something VS could do?

120 points by svenfaw 10y ago

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.

nailer 10y ago

> In the immortal words of Sherman T. Potter: “Horse hucky!” ?

wolfgke 10y ago
Sherman T. Potter > http://mash.wikia.com/wiki/Sherman_T._Potter http://mash.wikia.com/wiki/Sherman_T._Potter horse huckey: > http://www.urbandictionary.com/define.php?term=horse%20hockey http://www.urbandictionary.com/define.php?term=horse%20hocke... Colonel Potter curses (“Horse hucky!” is at the beginning): > https://www.youtube.com/watch?v=vhagzSEXzic https://www.youtube.com/watch?v=vhagzSEXzic

mtdewcmu 10y ago

I only have VS2010, but I always felt that VS stacked up pretty well against the competition, performance-wise. Eclipse always seemed painfully slow, and Xcode hasn't really impressed with its performance. That's no reason to rest on your laurels, surely. But at least VS shows some evidence of restraint in abusing resources.

taude 10y ago
I agree for the most part. But Eclipse has gotten a bit better in the recent years. I'm mostly on Intelli-J now, but when I was forced into Eclipse for a project, I didn't completely cry.
alkonaut 10y ago
The big perf drop in VS was between 2013 and 2015 when Roslyn was introduced (not sure if that's the reason though). It has improved somewhat in 2017 but I still find 2013 to be significantly faster than 2017.

draw_down 10y ago

Hmm. We must all be a bunch of rubes for running 64-bit code in so many places these days.

draw_down 10y ago
The mob has spoken! 64-bit is actually good.

sherincall 10y ago

I really wish MSFT would support the x32 ABI[0]. While having a single amd64 ABI, compared to 6-7 active in the x86 days, has its advantages, MSFT already threw it away with vectorcall. And x32 is arguable more useful than vectorcall. [0]: https://en.wikipedia.org/wiki/X32_ABI https://en.wikipedia.org/wiki/X32_ABI

wolfgke 10y ago
An ABI for amd64 was consciously developed independently by the gcc developers and Microsoft. Microsoft did "the obvious thing" and extended __fastcall to define their ABI. Here are links about this topic: > http://stackoverflow.com/a/35619528/497193 http://stackoverflow.com/a/35619528/497193 > http://stackoverflow.com/a/4438515/497193 http://stackoverflow.com/a/4438515/497193 > http://stackoverflow.com/a/35621290/497193 http://stackoverflow.com/a/35621290/497193
sp332 10y ago
I already have 32-bit and 64-bit copies of all the libraries on my computer. I'm really not looking forward to having a third copy lying around.
fsfod 10y ago
There are some ugly hacks[0] to run 64 bit code in a 32 bit process on windows by using retf switch to 64 bit code segment with one of the major limitations being you can't load 64 dlls into the process. [0]: http://blog.rewolf.pl/blog/?p=102 http://blog.rewolf.pl/blog/?p=102

marktucker 10y ago

In my experience, Visual Studio performance has improved significantly since VS2010, but if you compare it to VC6, it's a joke. There's still an old PC at the office running it, and double clicking a project opens the IDE and loads the project in less than a second. It's beautiful.

roel_v 10y ago
Sure, but it does so much more than VC6 used to do. I mean, the intellisense is so good nowadays, the continuous compiling that essentially gives you on the fly 'compiler errors', ... I agree that it would probably be nice if those could be turned off, and the UI is sluggish, but VC6 was (apart from being fast) not much to write home about (compared to what we have now).
- BinaryIdiot 10y ago
  To be fair though parent was referring to VC6's start-up time compared to the current version's start-up time. Is it fair to expect continuous compilation or maybe even intenseness to slow down start-up? I'm not so sure.
- orcy 10y ago
  We still build some stuff with VS2005 and it feels very fast and responsive while having everything I usually need in ide. The only thing it missing is modern C++ compiler.
whitefish 10y ago
Couldn't you say this about the software industry in general? In the 90's I used to have a Sun workstation on my desk. It ran the powerful Solaris operating system, but had just 16MB of RAM! Today you need 1GB of RAM to run an OS comfortably. My question: what does modern Linux do that Solaris from the 90's did not, that it requires 50x more memory?
- oblio 10y ago
  Well, I don't know, could your Solaris (mostly) seamlessly connect and disconnect to wireless networks? I don't even think there were that many wireless networks in the world back then :) Anyway, this is is just 1 contrived example of something modern OSs do, and that OSs from the 90's didn't do. Sure, there's some bloat, but a lot of it is the "Mozilla kind": "Mozilla is big not because it is full of useless crap. It is big because your needs are big".

taspeotis 10y ago

Run devenv /safemode to load the IDE without third party extensions (think ReSharper) and the thing flies. It's not Microsoft's code that's the problem.

Splines 10y ago
Yeah - my work instance of VS is sluggish as hell, and I sometimes load up a separate instance with toy problems to prototype ideas and it's practically as light as notepad.
BinaryIdiot 10y ago
We...may have different definitions of "flies". Yes if you disable third party plugins then it should be fast at various points in its lifecycle. At the same time it's not really that fast when you have zero plugins installed...
alkonaut 10y ago
This might be the case - but the IDE isn't really complete withiut extensions. I need svn integration, and I need basic refactoring from R# like "move type to new file". The problem is probably that memory is crowded and plugins must do a lot in-process via COM. If Microsoft really wanted to make VS fly for a lot of people they could just add the 10% most popular features from the 10most popular extensions. It would want nothing more than to throw out R#

oobey 10y ago

Would he have made those same comments to resist going from 16 to 32 bit? Hell, why not stick with 8 bit? We can just optimize everything to work on that, right?

kazinator 10y ago
More is always better. Four wheels is better than two; cars should have eight wheels. Look at GUID partition tables. With MBR, we had to hobble along with only a byte to identify partition types. Now we have 128 bits. We can finally support more filesystem kinds now than there are atoms in the Sun, all in one system installation, and the bootloader just has to look at the GUID. A 32 bit "fourcc" partition label clearly wouldn't have been enough.
- XorNot 10y ago
  GUID partition tables mean we don't need to coordinate identifiers. That's the point.
  - kazinator 10y ago
    But in fact, we don't need to coordinate identifiers. Clashes in partition ID's are of no practical consequence. A 32 bit "fourCC" would be more than adequate. It could even be constrained just to readable characters, like LNXF (Linux Filesystem) and LNXS (Linux Swap). If another OS happens to use LNXF for something, and you have that OS in the same darn system, it doesn't matter. You just don't have that "foreign" LNXF in your /etc/fstab, and likewise it doesn't have the Linux ones in its equivalent of /etc/fstab. The only thing that needs a clash-free label is the EFI boot partition, so the boot firmware can unambiguously identify all these partitions on all attached devices and offer them as boot options.
    - XorNot 10y ago
      Why have them at all then? If the argument you want to make is that they are of no consequence, then you need to answer why your proposal of still doing something is warranted.

eb0la 10y ago

I remember people favoring the use of their 32bit JVM instead of the 64-bit one for performance reasons but didn't wondered why. Makes sense if you're running Java with -Xmx1024m

loganmhb 10y ago
When reading about Elasticsearch I was fascinated to learn that the JVM can often use 32-bit object pointers to address about 32GB of RAM when running in 64-bit mode: https://wiki.openjdk.java.net/display/HotSpot/CompressedOops https://wiki.openjdk.java.net/display/HotSpot/CompressedOops
- will_hughes 10y ago
  As someone who comes from the .NET world, this is something that pissed me off about configuring Java applications like Elastic. If I've got a box with 512GB of ram, it seems I'm supposed to spin up multiple instances to satisfy this, all because the JVM has a hissy fit if you go over ~30GB. This then means worrying about replication and ensuring we don't have both the primary and replicas sitting on the same box. It seems insane that this is an actual issue in 2017.
  - wolfgke 10y ago
    > If I've got a box with 512GB of ram, it seems I'm supposed to spin up multiple instances to satisfy this, all because the JVM has a hissy fit if you go over ~30GB. What is the actual technical reason why the JVM cannot (easily?) address more than 32 GiB of RAM?
    - masklinn 10y ago
      I don't believe that's the case (an other commenter notes they run solr processes up to 160GB), however they may have run into the compressed oops optimisation, or more precisely the end of it: because Java is a very pointer-heavy language, if the maximum heap size is under 32GB many 64b JVMs use a variant of tagged pointers where they have 35 bit pointers stored in 32 bits (since the lower 3 bits are always empty they can shift them in/out). Except once you breach the 32GB limit, your 32 bit pointers grow to 64, and depending on your application you might need to grow your maximum heap into the high 40s to get room for new objects: https://blog.codecentric.de/en/2014/02/35gb-heap-less-32gb-java-jvm-memory-oddities/ https://blog.codecentric.de/en/2014/02/35gb-heap-less-32gb-j...

andrewvijay 10y ago

I only work on higher level languages like js and Python. Makes me realize how much I need to know about performance before I complain about IDEs.

BinaryIdiot 10y ago

I remember his original post back in 2009 and being very unsatisfied. I wanted the 64-bit transition only so I could properly use my tools at work (used to work in a .Net shop). We had resharper and several other plugins that ran in the same Visual Studio process as everything else and it was fairly common to hit the memory limit of a 32-bit process and Visual Studio would essentially die until it was killed and restarted. Sure, you can say "stop using those tools" or "they should have written them better". But at the time I was required to use most of them (it wasn't only Resharper though Resharper was pretty nice). Today I don't have this problem anymore. But I think because of that type of issue it would still likely be worth it. Honestly I feel like they could optimize Visual Studio at the same time; it has a ton of capability but it's also incredibly large and, from my understanding, carries a TON of legacy code and resources throughout.

ygra 10y ago
I guess his original point was that while moving to 64 bit would help the few users who actually hit memory allocation limits, it would also be a monumental effort for a project the size of Visual Studio to do so, including out-of-process support for 32-bit extensions to maintain compatibility, probably rethinking designers and debugging along the way. And all that to make things actually slower and taking more memory for everyone. His argument wasn't entirely »Stop using those tools while we do nothing at all«. It was »They should have done the right thing, but we'll also work towards making Visual Studio take less memory«. Especially considering that not leading everything you might eventually ever need at once in the beginning has probably a much smaller compatibility impact than upgrading significant parts of the IDE.

sp332 10y ago

Security can improve with 64-bit as well. It's a lot harder to break ASLR in a 64-bit address space than a 32-bit one. Though again, that might not apply to VS where a user can get "arbitrary code execution" by design.

Cyph0n 10y ago
That's assuming high entropy for address randomization of course. A 64-bit OS that has a weak ASLR implementation could end up weaker than a 32-bit OS that implements ASLR correctly. Your point definitely stands if both are well made.
rrdharan 10y ago
You might still care about security properties/exploits in Visual Studio given that a lot of use cases involve running it as Administrator: https://tomssl.com/2015/03/31/always-run-visual-studio-as-administrator-with-no-uac-prompt/ https://tomssl.com/2015/03/31/always-run-visual-studio-as-ad... I mean realistically don't know how much of a concern this is, but it's conceivable you might be running Visual Studio with elevated permissions on a shared machine and in turn want the ASLR protections.

snnn 10y ago

Right now, I'm fighting with: "fatal error LNK1248: image size (1004CB720) exceeds maximum allowable size (FFFFFFFF)" :-(

ygra 10y ago
That has nothing to do with Visual Studio, though. There is a 64-bit linker and you can use it.
- snnn 10y ago
  I already set toolset to x64. It's 64 bits cl.exe running.
mrich 10y ago
You will have to split up your library. There is also a limit for PDB files of 1GB, which can be workarounded to 2GB, but from the error above I think you are not hitting this limit.
- snnn 10y ago
  Thanks for your help.

to3m 10y ago

"Any packages that really need that much memory could be built in their own 64-bit process and seamlessly integrated into VS" Wait... did you just tell me to go fuck myself? ;)

recursive 10y ago
I believe he did, Bob.

codeflo 10y ago

At work, I have a fast machine with 32 GB of RAM, of which Visual Studio can only access about 3 GB. About once a month, Visual Studio crashes with some kind of out-of-memory error, and more often than that, it slows down to a crawl because it has to garbage collect every few seconds in an attempt to keep its memory usage below this magic limit. Even though the machine has 20 GB of free RAM that Visual Studio just can't use. The author acknowledges that this can happen: > So, you’re now out of address space. There are two ways you could try to address this. > a) Think carefully about your data representation and encode it in a more compact fashion > b) Allow the program to just use more memory > I’m the performance guy so of course I’m going to recommend that first option. As a "performance guy", he should know that using a bit more RAM is essentially free, and much, much easier to code than doing the kind of bit-fiddling wizardry he suggests ("encode it in a more compact fashion"). In practice, that kind of low-level code will not get written anyway, at least not by modern Microsoft, and much less so by most extension authors. Which means that there's an arbitrary and very hard limit on how much you can customize/extend Visual Studio before you hit that 3 GB wall. And again, this is on modern workstation machines with gigabytes of unused RAM lying around. In short, there may be very valid technical reasons why VS can't go 64-bit, but to claim that this doesn't hurt the product is in my opinion not justified.

bicubic 10y ago
Considering the 64 bit support problem has been going on for over five years now and the magical 3GB limit is increasingly absurd on modern hardware, I wonder if they've considered just giving up on VS and doubling down on VS Code. It also sorts out their desperate need for a UI overhaul.
- brynjolf 10y ago
  Visual Studio Code is slow in comparison to VS. It has way less features. I hope this is not the path they take.
  - chillee 10y ago
    It's not slower than VS. It's just not an IDE.

SadWebDeveloper 10y ago

tl;dr... its humongous task and we are busy adding more "instant azure buying-options aka deployment tools", it will only benefit 1% of our users and we also want to keep milking this cow until the shit hit the fan.

kabdib 10y ago

This is a pretty myopic view of performance and 32-bit code. - You really only get 3GB of RAM - Actually, you get less than that, because of DLLs that get loaded into that space. - Actually actually, fragmentation becomes a problem, and making very good use of the remaining memory gets awkward pretty quickly. 3GB is pretty crowded, especially when you're talking about (say) a game with tens of GB of footprint. You need to page stuff into that footprint, and be clever about the memory pressure not affecting the user experience. On the server side of things, we regularly run processes with > 8GB footprints, including things like solr (at 32 to 160GB). Breaking this stuff up would involve a lot more disk and network chatter, as well as bugs involving OOM conditions, reducing global performance and reliability. So while VS may be fine with 32-bit code+data (I am not convinced), real-world applications definitely need more. I'm guessing that making a 64-bit VS is hard for legacy reasons, and that the 32-bit space is actually holding the VS team back (and possibly plugin makers as well).

masklinn 10y ago
> So while VS may be fine with 32-bit code+data (I am not convinced) Many people in this thread and the corresponding one on reddit report VS regularly crashing on OOM or eating all the CPU garbage-collecting nonstop as it gets closer and closer to the limit.

aussie123 10y ago

The author seems to be defensive, trying to justify the status quo. I would be interested what the real reasons are. Why have most other Microsoft products moved to 64bit but VS was hesitant from the beginning?

blauditore 10y ago

Disclaimer: I don't know too much about this field Can someone explain why exactly 64-bit is generally slower than 32-bit? I understand that more RAM will be used and I/O to it slowed down due to double the bits pushed around since "chunks" have double the length, which ends up being a lot of empty padding (is that correct?). But everything inside the CPU, like registers or ALUs, are 64 bits wide anyway (right?), so computing in 64-bit mode would just make use of resources that were unoccupied in 32-bit mode. Or am I missing something?

jcranmer 10y ago
The primary resource that's going to be hit is the cache. You get 8MB of cache whether you're in 32-bit mode or 64-bit mode. Switching to 64-bit mode means that you have half as much cache in terms of number of pointer fields you can store. Note this can also impact alignment of fields within structs--if you're on 64-bit, you want your pointers to appear before 32-bit fields; if you alternate, you waste a lot of extra space.
- deleted 10y ago
  [deleted]
vvanders 10y ago
Cache sizes are fixed to less things fit in L1/L2 than did before.
robert_foss 10y ago
Because addresses are longer they will take up more space, which will lead to your CPUs instruction-cache (I-Cache) being more full, which directly translates into performance losses due to needed things being evicted from I-Cache. The same is true for L1/L2/L3 caches too. The same is true to a much lesser extent for taking up more space in ram, and to an even lesser extent for reading things from storage.
- tigershark 10y ago
  This is true for non x86 architectures. Translating an x86 software to x64 brings performance benefits most of the times because of the ability to use the additional registers non accessible in x86 mode.

rikkus 10y ago

When I'm working on performance, I measure twice and cut once. I know measuring is 'hard' as there's a lot of code optimised for x86 in VS, but saying 'It would be slower built for 64 bit' is cutting before measuring even once. I have the greatest of respect for the author, but everyone needs to be exposed to 'trust, but verify' at least occasionally, just in case they happen to be wrong this once.

tpolm 10y ago

"The one who wants - seeks ways, who does not want - seeks a reason"

TillE 10y ago
That's pretty apt. There are always legitimate reasons why doing something is difficult and imperfect, but there's a really clear future here. It's absurd to think that Visual Studio will remain 32-bit in 10 or 20 years' time. And no, as any C++ developer will tell you, the answer is not to move to a souped-up text editor (Visual Studio Code).

tpolm 10y ago

"The one who wants - seeks ways, who does not want - seeks a reason"

tpolm 10y ago

2016 follow-up from the same "I regret I did this" person https://blogs.msdn.microsoft.com/ricom/2016/01/04/64-bit-visual-studio-the-pro-64-argument/ https://blogs.msdn.microsoft.com/ricom/2016/01/04/64-bit-vis...

moogly 10y ago

I don't see the point of this article. The VS team has moved more and more stuff out-of-process. VS 2015 can easily use more than 4 GB (if you're working in medium to large solutions), but it's divided up across 3-4 main processes. MSBuild processes (normally 1 per thread) are also staying around for 15 minutes now, so they can be reused.

slededit 10y ago
Where it falls down is if the debugger tries to load more than 3GB of symbols. Guaranteed crash every single time. You can manually limit the symbols it loads - but that doesn't apply to other parts like the profiler which will still crash deterministically.

gwern 10y ago

"Because virtually invariably the reason that programs are running out of memory is that they have chosen a strategy that requires huge amounts of data to be resident in order for them to work properly. Most of the time this is a fundamentally poor choice in the first place. Remember good locality gives you speed and big data structures are slow. They were slow even when they fit in memory, because less of them fits in cache. They aren’t getting any faster by getting bigger, they’re getting slower. Good data design includes affordances for the kinds of searches/updates that have to be done and makes it so that in general only a tiny fraction of the data actually needs to be resident to perform those operations. This happens all the time in basically every scalable system you ever encounter. Naturally I would want people to do this. ...In the VS space there are huge offenders. My favorite to complain about are the language services, which notoriously load huge amounts of data about my whole solution so as to provide Intellisense about a tiny fraction of it. That doesn’t seem to have changed since 2010." But I'm sure that by remaining 32-bit, in another 5 years maybe everyone will magically optimize their stuff... Any second now...

MrBuddyCasino 10y ago

The JVM has a neat trick where it uses 32 bit pointers up to 32GB heap sizes, because alignment is 8 bytes and so there are really only 1/8th distinct possible memory adresses for the whole adress space, so you can just easily map them. Is this something VS could do?