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?
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).
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.)
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.
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.
> 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.
Yes, it has its occasional uses and is still supported, but the point is that x86-64 got a noticable FP capability boost through the doubling of the SSE registers compared to 32-bit x86. SSE is not just for SIMD, it has single/double scalar instructions as well, which mostly replace the old FPU.
If you look at generic floating point code generated for x86 by any modern C/C++ compiler, you won't see any FPU use, it's all SSE scalar, and occasionally SIMD for clever compilers.
There was a nice thread last week about bugs due to the internal 80-bit representation in the old FPU. IMHO it should have been deprecated long ago and x64_64 should have disallowed its use entirely. There are 128bit FP these days implemented with new hardware and instructions.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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?
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".
Isn't a significant chunk of OS memory usage caused by the desktop UI? If we're talking about servers, I'm guessing it would be because of drivers and more built-in functionality, some of which is rarely used.
Yeah — the image buffers (screen resolutions) are bigger, we run more apps, more advanced desktop environments… also in the old days (before OS X, Compiz (fun with desktop cubes!) and Vista Aero) people used to run without compositing, which meant one common image for all apps to draw into.
Just booted my laptop (FreeBSD -current amd64, 1366x768 display) and started X: only 204M "Active" memory. Of the 204M: 60M is syncthing, 39M compton, 31M Xorg, 11M i3bar, 11M polkitd, 10M i3, 9M dunst, 5M wpa-supplicant… Not counting syncthing that's 144 megabytes. I think that looks reasonable. You can go lower and optimize for low memory (no polkit, no compton — 94M) or go higher and optimize for usability and fancy UI features (install gnome :D)
> 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 :)
Let alone USB. During my training, there were lots of desktops running Windows NT 4.0, which did not know USB. By the time I had already become so used to copying data back and forth with a USB thumb drive (even though back then their capacity was still measured in megabytes), that it became fairly annoying to walk up to some computer, plug in the thumb drive, then realize this machine is running NT 4.0, not Windows 2000, cursing, then looking for another way to get some piece of data on that computer: Usually put it on some other machine copy it over the network.
> Anyway, this is is just 1 contrived example of something modern OSs do, and that OSs from the 90's didn't do.
This doesn't add anything, because contrived or not, it doesn't answer the question that was posed: "What does modern Linux do that Solaris from the 90's did not, that it requires 50x more memory?"
It hits the first part of the question, but not the second part. We could add wifi to a 90s OS without severely inflating the memory requirements. My Nintendo DS (with 4MB RAM) "seamlessly connects and disconnects to wireless networks", after all.
You could easily answer the question with a sensible, non-contrived answer, and I'm not sure why you didn't.
If you set up your Linux distro from scratch you can easily manage under 200MB of RAM. I have an LFS I set up which idles at 150MB or so. A LOT of stuff is bloat in modern distributions.
I recommend everyone to try and build an LFS (Linux From Scratch) at least once or at least set up an ArchLinux box to get a feel for how Linux actually works and where the bloat is.
As an example, the music player daemon (MPD) has 110 dependencies among which is wayland or x-org, I don't know why.
Also, using udev to only load needed kernel modules helps with a lot of memory usage.
Can you recommend any good tools for measuring and plotting overall system memory usage over time? I always thought it would be a fun project to try to strip down a Linux distribution and see how low I could get worst-case memory usage.
You can simply pipe top's output to a file using something like cron. There is a very good tool for boot times though integrated into systemd. Call it using `systemd-analyze`. It has a lot of subcommands you can check by `systemd-analyze --help`.
Also, if you'd like to compare performance degradation over time, NixOS is a good choice to run because it can simply rollback to old configurations and you can see what changed.
I'm not sure if you're serious, but modern linux does a lot of things that solaris didn't do back then. A few more points: my linux system ran "OK" with 8MB RAM in 1995, although it started to swap when I ran emacs, X11, and g++ at the same time (this was ultimately fixed by maxxing out the RAM to 32MB).
I have small Linux systems today that work comfortable with 128MB of RAM used.
What my modern linux system does that Solaris didn't do in the 90s: runs a browser than can render absurdly detailed scenes using OpenGL where the object model itself exceeds 1GB (it fits nicely on the graphics card, but the computer is also loading that from the net at gigabit speeds and storing another copy in RAM).
That said, I think it's true that modern systems just waste oodles of resources unnecessarily.
the "exotic" machine at the time was a Digital Alpha (64 bit! In 1995) that had 64MB IIRC. It did fly. The solaris machines we used took 20 minuts to boot and another 1 minute to open a shell.
We had Indys with 32MB of RAM in '97-98. They were basically useless- the OpenGL implementation wasn't that great, and the rest of the system was massively underprovisioned (constant slow disk IO). However, we also had a bunch of better SGIs with 64+MB of RAM and those worked great.
I often wonder the same. In '90 I helped build a primitive web browser, including an interpretive language. Used it to instrument a couple nuclear power plants. Displays were graphically rich, and had to load in < 1 sec and display real-time plant data. I don't ever recall waiting for my IDE (emacs) to start, or even waiting very long for a full build to complete.
When we have less, we make due with less. When we have more, we consume more. It's sort of like money.
Forgive the nitpick, but it is "make do", if only because "make due" reads very awkwardly in British English where "due" is pronounced as if it is spelled with a U and an E, not as if it is spelled with two O's
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.
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.
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...
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#
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.
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.
Because we can usefully assign distinct values in a context like "Windows plus Linux box" in which we don't care about some exotic file system that was once used on a DEC VAX or whatever.
So why not use a single byte? How many machines do you know which have more then 255 filesystems on the one disk?
Why not a nibble and just use the other 4 bits for flags?
The point of this line of questioning is you're quibling over bytes which definitely don't matter in any modern context, at the expense of masses of extra management complexity to try and avoid day-to-day problems when people want to stand up new systems.
With GPT, if I want to make a new filesystem type for some application, I just generate a GUID and it will not collide without me needing to coordinate with anyone.
Indeed; one byte works for me. Four is a reasonable political compromise between "one byte works for me" and "oh my, what about clashes?"
16 bytes is an obvious example of the "second system effect" described by Fred Brooks in Mythical Man Month.
The fdisk utility now reduces the GUIDs to one byte codes that refer to the GUIDs. For instance, I remember that 29 is Linux RAID (previously FD). Will 29 always be Linux RAID everywhere? Probably not.
> With GPT, if I want to make a new filesystem type for some application ...
Four bytes could have an ample reserved range for local use by hobbyists.
Broad recognition of the code only matters if the application is very widely deployed.
No. With 8 bit you had to execute multiple instructions to add two numbers. Same with 16 bit. This problem went away with 32 bit. Adding more bits beyond 32 does not bring proportional benefits because the numbers we deal with fit in 32 bit.
> No. With 8 bit you had to execute multiple instructions to add two numbers. Same with 16 bit.
Wrong (for x86-16 vs. x86-32). Just use an operand-size size override prefix (0x66) with your 16 bit real mode ALU (in this case 'add') instruction to make it a 32 bit ALU instruction. Works from 80386 on, where the 32 bit registers were introduced.
I agree, most numbers we deal with fit in 32 bits with the exception of double precision floating point and indexes for really large data sets. As Moore's law seems to be ending perhaps there might be a sweet spot at 48bits for both integer and FP.
The one thing I found absurd with RISC-V is the 128bit variant. Most 64bit processors today don't even support a full 64bit virtual address space do they?
My interpretation of the shift from < 32 bits into 32 bits is: before we had do do crazy things to algorithms we used to fit in those address spaces. When we transitioned to 32 bits, we didn't have to do that anymore.
So the question might be are there any surprising workarounds in the code because you're only dealing with 32 bit code where if you had 64 bits you could write some more elegant solution.
It's not exactly what you're asking for, but you'll run into a big one in about two decades.
The only other example I can think of is the general "problem" of large databases. There's just a lot more paging and churn that has to happen in a 32-bit address space. Many NoSQL databases in particular have a memory model of mmap'ing an entire database, which runs into a hard limit on 32-bit address space.
You could continue this argument out to 128 or 256 bits. Where it starts to fall down is when you map the size of those address spaces back to the data types people work with.
In a 16-bit address space (64K), you hit the 16-bit limit _all the time_. Even a moderately sized text document will be bigger than 64K... and that's before considering images, videos, large data sets, etc.
32-bit takes you out to 4GB, which is much more likely to hold a typical working set, so the argument to go to 64-bit is much less pressing.
"why not stick with 8 bit?"
This conversation is about the size of the address space, not the machine word size. To my knowledge, there were no serious machines of any sort that were limited to an 8-bit address space. (Maybe something homebrew or embedded.) The closest I can think of is the 6502's preference for putting values in the zero page (which was 256 bytes).
> In a 16-bit address space (64K), you hit the 16-bit limit _all the time_.
Depends on the way 16 bit is implemented. For example x86-16 uses segmented memory - enabling adressing of a little bit more (including High Memory Area) than 1 MiB of memory. The Z180 uses as far as I know a MMU (but not completely sure). Another approach that is/was in common use is to use bank switching.
Depending on the kind of algorithm that you use this can make the coding much more complicated or can also be no problem, because the scheme that is used to address more memory than 2^16 bytes fits the algorithm quite natural.
One interesting hack for example when coding in real mode (x86-16) that I read about is rather to use some clever sharing of bits between the segment register value and segment index:
- One scheme is to consider the value of the used segment register as a pointer to a 16 byte block of memory and use the segment index to adress the specific byte in this block (with an option to increase the index "a little bit" if you want to go further)
- Another scheme is to (mostly) use only the 4 highest bits of the segment register (and zero all the other ones).
"One scheme is to consider the value of the used segment register as a pointer to a 16 byte block of memory and use the segment index to adress the specific byte in this block (with an option to increase the index "a little bit" if you want to go further)"
This only works in real mode, where the segment is shifted and directly added to the offset. In protected mode, it goes through a selector table. This can be made to work too, but it requires tiled allocations of segments with known delta between each segment. This is what __ahincr was about, if you remember it from the Win16 days.
Are you thinking of a specific concrete 16-bit architecture where it's easy to access data objects larger than 64K?
I'd be interested to hears... I really can't. Probably the most capable architecture I'm familiar with that has a native 16-bit pointer type is the 80286, which provides 24-bit physical addressing, virtualizatoin, protections, etc. Even then, at least on Windows, key local heaps within the OS were confined to 64K, the default text editor was confined to a segment... writing image processing tools (which I did) required special handling for all but the smallest scale workloads. These all added to developer workload and reduced system capacity in unfortunate ways.
I get what you're saying that there are exceptions and hacks that make it possible to work within these limitations, but my point is that you have to care about them on 16-bit, and most of the time you really don't on 32-bit. My thesis for why that is goes back to what I was saying initially about the size of the core data types people tend to manipulate.
(And this goes back to the reason I posted in the first place, which was to explain the relative difference in motivation between the 16->32 switch and the 32->64 switch.)
> Are you thinking of a specific concrete 16-bit architecture where it's easy to access data objects larger than 64K?
Your question implies that you want one piece > 64 KiB of flat memory. With this you already stated a very strong implicit assumption about the data layout and the kind of algorithm that you want to use. My point rather is: Consider the capabilities that the 16b machine has and try to fit the data representation and algorithms that you use around it instead of wining about lack of machine capabilities. One will often find a solution using clever tricks that one would not have considered otherwise, which will often turn out to be surprisingly elegant and much better than the "naive" solution.
This way to program is of course nothing for the kind of programmer that want to write an unelegant and just working program in a short amount of time, I know. :-)
> Consider the capabilities that the 16b machine ...instead of wining about lack of machine capabilities. ...the kind of programmer that want to write an unelegant and just working program in a short amount of time,
I do hear you, but one of the things I love about virtually all modern hardware is just how much capability it puts within the reach of totally naive and quick development strategies. If I can inelegantly solve two or three problems in the same time I can elegantly solve one, then that strikes me as a net win (at least for the people that need problems solved more than code written.)
I don't mind pushing the hardware and searching for elegance, but I'd rather be forced into it by the necessities of the problem I'm trying to solve.
No, because the steps are exponential. You can sit down and type your way through 64k. If this was an argument by induction, then 1 bit would have been fine too.
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.
> 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?
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-j...
The JVM can use 32 GB of heap when running in 32 bits mode. That's not a comparable limitations to a standard 32 bits app that will invariably crash at 2-3 GB.
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.
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.
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.
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.
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.
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.
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.
I really hope it is. I don't really find VS Code to be any slower than VS. Of course, this depends on what you're using each for. I find I prefer VS Code because it has so few default features. The default install does not contain GB of bloat that I will never need. I'm able to build the experience I want, rather than fight one thrust upon me.
I don't know precisely what the default install size is for Visual Studio 2017, but with the new installer, a Visual Studio install can be svelte relative to previous releases.
It's still large relative to VS Code and other editors of course. But the "gigabytes of bloat" problem with Visual Studio isn't so much the case now.
"I don't really find VS Code to be any slower than VS."
Given VS Code has a fraction of the features VS has, it should be noticeably faster. It will eventually be GB of bloat and slower than VS.
What I'd like to see instead is features being broken out into separate components that can be used by any other editor/tool. Of course, if every component is going to required it's own dot file in my home directory to (maybe) turn off telemetry, I won't touch it, so I'd rather see those things developed by someone other than MS.
You have a very different experience with VS than I have... right now, I'm waiting half an hour, so I can check out a branch from vsts, so I can wait another 6-8 minutes to build my solution, etc... it's painfully slow... VS Code, edit, next...
I've only seen VS Code run slow if you're running on 2gb of ram, or have hundreds of competing plugins installed, and even then. VS Code is way better than VS proper from my own subjective experience.
The plan that they seem to be following is to convert VS into a completely managed memory product and then move to 64 bit. It's easier and doesn't introduce a feature-freeze period for a project the size of Visual Studio.
You can sort of imagine that there is a faction that hates the idea of moving to managed code, and that is causing an impasse.
Personally, attaching a managed code port to the 64-bit migration sounds misguided. The managed code port sounds much more involved and disruptive than migrating the existing native code would be. It's probably some manager's pet project and it makes no technical sense.
There are already large chunks of managed code in VS. It might be that they are pushing to fully convert to managed code for other reasons, and as a side benefit they get 64-bit support for "free".
Probably the parts that are still in native code include stuff that is performance-sensitive, like the guts of the compilers. It's probably intricate and finely-tuned.
.NET Native is new to me. It looks like it helps CIL languages to perform better. I'm not sure what it does to C/C++. I can't tell what the grand strategy is, but I guess they are catching up to Apple in some ways. It's amazing what Microsoft's resources allows them to do. Apple uses LLVM, and, of course, they would not be Microsoft if they adopted LLVM. Microsoft writes their own LLVM from scratch.
I think it's good to have additional implementations, even if they are rather insular about it.
Microsoft Research is the genuine article. It's a world class research institution.
I guess Phoenixey/LLVM type stuff is probably the way the winds were blowing in the compiler community at large. It's interesting how a lot of things that used to seem impossible are now in multiple software packages.
You figure that once MS is rolling out a compiler technology in a big way, it can't get much more mainstream than that.
I still don't totally understand why it was important for MS to push into JIT-compiled bytecode on Windows. From the end-user's standpoint, it just makes software slower.
Really? I find that really surprising. Because VS itself isn't anywhere close to a wonderful text editor.
Like most IDE's, it is a mediocre text editor with a bunch of compelling (for certain workflows) tooling for project and build management, debugger, etc. Plus usable introspection. As a text editor though, a solid C+ at best.
Is VS Code someone doing something radically different?
VS Code started with atom shell (now electron), and a JS based editor that was being worked on for VisualStudio online... combined they were pretty compelling, and at the time so much faster than say Atom or Brackets... It's been my editor of choice since first trying it and only better with each regular release. The entire thing is opensource.
Completely open source, rich plugin/extension community. Pretty much has become the editor of choice if you're working on node or go... more than decent with other platforms, and as a general editor. There are extensions to improve workflows, but all optional extensions.
I have git history, git lense, eslint, docker, c# (works for .net core), go, jest, npm, npm intellisense, yandex-translate (makes vscode worthwhile by itself), and a couple others.
I don't think I can go back... having the treeview, git integration, integrated console, it's all just way awesome to say the least.
It's a false choice. 64-bit is the future, right? So the 64-bit transition is probably approaching inexorably. Optimizing data structures will be just as good in 64-bit. Actually, it will be even better, because the wasteful data structures will then expend twice as much memory on pointers and become even more wasteful.
Since I'm a "performance guy" I use vim ... which has been 64-bit compatible since last century.
Sure, Visual Studio is a much much bigger challenge to make compatible. But come on, they've had over a decade during which it was obvious it should be 64bit compatible! A decade!
During the same decade-long timeframe they should have been working on lifting the 260 char path limit, another bug they "wontfix".
My guess is that they've had really strong product management - they really prioritize those snazzy features and releases, but aren't allowed to spend any time on the technical debt. (And, seriously, they've had a decade ...)
It was fixed in Windows :) Any application can add a manifest entry to enable long paths. The .Net change is because .Net needed to expose / add support for it in addition to the base OS supporting it.
I'm half surprised that wasn't in NT4 (prior to 2000 even)... been a major thing that pissed me off in .Net a couple years ago... "why in freaking 2014 is this still a problem?!?!"
Was really happy to see it was finally fixed in .Net and the Anniversary update, and long, long overdue.
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.
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).
> 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.
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?
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?
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.
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.
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.
>>> Can someone explain why exactly 64-bit is generally slower than 32-bit?
It's an incorrect yet popular assumption on the internet.
64 bits pointers take more space, which affects caching => Slower
64 bits architectures have more registers and instructions, and it removes the need to have an intermediate 32to64bit abstraction layer from the OS => Faster.
Overall, the side effects are extremely complex.
Moving an application from 32 to 64 bits is as likely to be 1% faster as to be 1% slower.
This has been my experience, too, mostly. I ran both a 32-bit and a 64-bit Linux desktop on an Athlon64, both for several months, and I did not notice a difference in performance.
About the only real benefit is that the system can handle more RAM (which of course is a good thing). For some applications that are very, very memory-hungry, this can improve performance dramatically, because the program no longer needs to juggle all that data and can just keep it in RAM.
Because no one else has mentioned it, paging is more expensive in 64-bit. In 64-bit, the kernel uses a 3 or 4 level page table requiring 3 or 4 SDRAM accesses on a TLB miss. 32-bit kernels can get away with 2 SDRAM accesses (PDE+PTE) if they're doing 32-to-32 translation. On a ~3GHz CPU, each uncached SDRAM access will cost the CPU about 200 cycles which means a worst-case 32-bit scenario would be about 400 cycles but 64-bit could reach +800 cycles.
This only applies to running a 64-bit kernel vs a 32-bit kernel; running a 32-bit process on a 64-bit kernel will incur the same page table cost as a 64-bit process.
Exactly, and I seriously doubt that in 2017 anyone is using a 32 bit OS with visual studio (I had to endure it in 2015 at work and I know very well what it means)
Agreed. And, while I have no evidence of this, my intuition is that the extra GPRs you get in 64-bit more than makes up for any minuscule system-wide performance hit 64-bit long-mode paging imposes.
Modern CPUs heavily cache (in L2 & L3) the page table entries (some even speculatively load them into cache), so actual DRAM accesses are rarely needed.
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.
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).
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.
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.
"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...
158 comments
[ 0.29 ms ] story [ 235 ms ] threadIn 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).
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.)
It's not "intel", it's x86. 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.
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.
If you look at generic floating point code generated for x86 by any modern C/C++ compiler, you won't see any FPU use, it's all SSE scalar, and occasionally SIMD for clever compilers.
?
> http://mash.wikia.com/wiki/Sherman_T._Potter
horse huckey:
> 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
[0]: https://en.wikipedia.org/wiki/X32_ABI
Here are links about this topic:
> http://stackoverflow.com/a/35619528/497193
> http://stackoverflow.com/a/4438515/497193
> http://stackoverflow.com/a/35621290/497193
[0]: http://blog.rewolf.pl/blog/?p=102
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).
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".
Just booted my laptop (FreeBSD -current amd64, 1366x768 display) and started X: only 204M "Active" memory. Of the 204M: 60M is syncthing, 39M compton, 31M Xorg, 11M i3bar, 11M polkitd, 10M i3, 9M dunst, 5M wpa-supplicant… Not counting syncthing that's 144 megabytes. I think that looks reasonable. You can go lower and optimize for low memory (no polkit, no compton — 94M) or go higher and optimize for usability and fancy UI features (install gnome :D)
Let alone USB. During my training, there were lots of desktops running Windows NT 4.0, which did not know USB. By the time I had already become so used to copying data back and forth with a USB thumb drive (even though back then their capacity was still measured in megabytes), that it became fairly annoying to walk up to some computer, plug in the thumb drive, then realize this machine is running NT 4.0, not Windows 2000, cursing, then looking for another way to get some piece of data on that computer: Usually put it on some other machine copy it over the network.
Ah, those were the days... ;-)
This doesn't add anything, because contrived or not, it doesn't answer the question that was posed: "What does modern Linux do that Solaris from the 90's did not, that it requires 50x more memory?"
It hits the first part of the question, but not the second part. We could add wifi to a 90s OS without severely inflating the memory requirements. My Nintendo DS (with 4MB RAM) "seamlessly connects and disconnects to wireless networks", after all.
You could easily answer the question with a sensible, non-contrived answer, and I'm not sure why you didn't.
I recommend everyone to try and build an LFS (Linux From Scratch) at least once or at least set up an ArchLinux box to get a feel for how Linux actually works and where the bloat is.
As an example, the music player daemon (MPD) has 110 dependencies among which is wayland or x-org, I don't know why.
Also, using udev to only load needed kernel modules helps with a lot of memory usage.
Also, if you'd like to compare performance degradation over time, NixOS is a good choice to run because it can simply rollback to old configurations and you can see what changed.
I have small Linux systems today that work comfortable with 128MB of RAM used.
What my modern linux system does that Solaris didn't do in the 90s: runs a browser than can render absurdly detailed scenes using OpenGL where the object model itself exceeds 1GB (it fits nicely on the graphics card, but the computer is also loading that from the net at gigabit speeds and storing another copy in RAM).
That said, I think it's true that modern systems just waste oodles of resources unnecessarily.
It's salutary to consider that the memory for a reasonably spec'd machine a little over 20 years ago is now a rounding error
I remember at about that time having 80MiB of RAM: a) my machine flew, and b) plenty of people would ask why I needed so much
https://en.wikipedia.org/wiki/SGI_Indy
https://en.wikipedia.org/wiki/IRIX
When we have less, we make due with less. When we have more, we consume more. It's sort of like money.
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#
Hell, why not stick with 8 bit? We can just optimize everything to work on that, right?
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.
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.
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.
Why not a nibble and just use the other 4 bits for flags?
The point of this line of questioning is you're quibling over bytes which definitely don't matter in any modern context, at the expense of masses of extra management complexity to try and avoid day-to-day problems when people want to stand up new systems.
With GPT, if I want to make a new filesystem type for some application, I just generate a GUID and it will not collide without me needing to coordinate with anyone.
16 bytes is an obvious example of the "second system effect" described by Fred Brooks in Mythical Man Month.
The fdisk utility now reduces the GUIDs to one byte codes that refer to the GUIDs. For instance, I remember that 29 is Linux RAID (previously FD). Will 29 always be Linux RAID everywhere? Probably not.
> With GPT, if I want to make a new filesystem type for some application ...
Four bytes could have an ample reserved range for local use by hobbyists.
Broad recognition of the code only matters if the application is very widely deployed.
Wrong (for x86-16 vs. x86-32). Just use an operand-size size override prefix (0x66) with your 16 bit real mode ALU (in this case 'add') instruction to make it a 32 bit ALU instruction. Works from 80386 on, where the 32 bit registers were introduced.
The one thing I found absurd with RISC-V is the 128bit variant. Most 64bit processors today don't even support a full 64bit virtual address space do they?
Except when they don't. Everyone already forgot tweet number 2147483648? :) https://techcrunch.com/2009/06/12/all-hell-may-break-loose-o...
My interpretation of the shift from < 32 bits into 32 bits is: before we had do do crazy things to algorithms we used to fit in those address spaces. When we transitioned to 32 bits, we didn't have to do that anymore.
So the question might be are there any surprising workarounds in the code because you're only dealing with 32 bit code where if you had 64 bits you could write some more elegant solution.
The only other example I can think of is the general "problem" of large databases. There's just a lot more paging and churn that has to happen in a 32-bit address space. Many NoSQL databases in particular have a memory model of mmap'ing an entire database, which runs into a hard limit on 32-bit address space.
In a 16-bit address space (64K), you hit the 16-bit limit _all the time_. Even a moderately sized text document will be bigger than 64K... and that's before considering images, videos, large data sets, etc.
32-bit takes you out to 4GB, which is much more likely to hold a typical working set, so the argument to go to 64-bit is much less pressing.
"why not stick with 8 bit?"
This conversation is about the size of the address space, not the machine word size. To my knowledge, there were no serious machines of any sort that were limited to an 8-bit address space. (Maybe something homebrew or embedded.) The closest I can think of is the 6502's preference for putting values in the zero page (which was 256 bytes).
Depends on the way 16 bit is implemented. For example x86-16 uses segmented memory - enabling adressing of a little bit more (including High Memory Area) than 1 MiB of memory. The Z180 uses as far as I know a MMU (but not completely sure). Another approach that is/was in common use is to use bank switching.
Depending on the kind of algorithm that you use this can make the coding much more complicated or can also be no problem, because the scheme that is used to address more memory than 2^16 bytes fits the algorithm quite natural.
One interesting hack for example when coding in real mode (x86-16) that I read about is rather to use some clever sharing of bits between the segment register value and segment index:
- One scheme is to consider the value of the used segment register as a pointer to a 16 byte block of memory and use the segment index to adress the specific byte in this block (with an option to increase the index "a little bit" if you want to go further)
- Another scheme is to (mostly) use only the 4 highest bits of the segment register (and zero all the other ones).
This only works in real mode, where the segment is shifted and directly added to the offset. In protected mode, it goes through a selector table. This can be made to work too, but it requires tiled allocations of segments with known delta between each segment. This is what __ahincr was about, if you remember it from the Win16 days.
Of course this is true. You wrote further above:
> In a 16-bit address space (64K), you hit the 16-bit limit _all the time_.
I wanted to outline that whether this is a problem or not depends a lot on the concrete 16 bit architecture.
I'd be interested to hears... I really can't. Probably the most capable architecture I'm familiar with that has a native 16-bit pointer type is the 80286, which provides 24-bit physical addressing, virtualizatoin, protections, etc. Even then, at least on Windows, key local heaps within the OS were confined to 64K, the default text editor was confined to a segment... writing image processing tools (which I did) required special handling for all but the smallest scale workloads. These all added to developer workload and reduced system capacity in unfortunate ways.
I get what you're saying that there are exceptions and hacks that make it possible to work within these limitations, but my point is that you have to care about them on 16-bit, and most of the time you really don't on 32-bit. My thesis for why that is goes back to what I was saying initially about the size of the core data types people tend to manipulate.
(And this goes back to the reason I posted in the first place, which was to explain the relative difference in motivation between the 16->32 switch and the 32->64 switch.)
Your question implies that you want one piece > 64 KiB of flat memory. With this you already stated a very strong implicit assumption about the data layout and the kind of algorithm that you want to use. My point rather is: Consider the capabilities that the 16b machine has and try to fit the data representation and algorithms that you use around it instead of wining about lack of machine capabilities. One will often find a solution using clever tricks that one would not have considered otherwise, which will often turn out to be surprisingly elegant and much better than the "naive" solution.
This way to program is of course nothing for the kind of programmer that want to write an unelegant and just working program in a short amount of time, I know. :-)
I do hear you, but one of the things I love about virtually all modern hardware is just how much capability it puts within the reach of totally naive and quick development strategies. If I can inelegantly solve two or three problems in the same time I can elegantly solve one, then that strikes me as a net win (at least for the people that need problems solved more than code written.)
I don't mind pushing the hardware and searching for elegance, but I'd rather be forced into it by the necessities of the problem I'm trying to solve.
Makes sense if you're running Java with -Xmx1024m
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.
What is the actual technical reason why the JVM cannot (easily?) address more than 32 GiB of RAM?
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-j...
https://www.elastic.co/guide/en/elasticsearch/guide/current/...
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.
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.
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.
Wait... did you just tell me to go fuck myself? ;)
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.
It's still large relative to VS Code and other editors of course. But the "gigabytes of bloat" problem with Visual Studio isn't so much the case now.
Given VS Code has a fraction of the features VS has, it should be noticeably faster. It will eventually be GB of bloat and slower than VS.
What I'd like to see instead is features being broken out into separate components that can be used by any other editor/tool. Of course, if every component is going to required it's own dot file in my home directory to (maybe) turn off telemetry, I won't touch it, so I'd rather see those things developed by someone other than MS.
I've only seen VS Code run slow if you're running on 2gb of ram, or have hundreds of competing plugins installed, and even then. VS Code is way better than VS proper from my own subjective experience.
Personally, attaching a managed code port to the 64-bit migration sounds misguided. The managed code port sounds much more involved and disruptive than migrating the existing native code would be. It's probably some manager's pet project and it makes no technical sense.
Now with Roslyn and .NET Native, they are planning to increasingly move more runtime stuff into C#.
.NET Native backend is of course shared with Visual C++, aka C2, a kind of Microsoft's own LLVM-like approach.
I think it's good to have additional implementations, even if they are rather insular about it.
It was called Project Phoenix, developed at MSR.
https://en.wikipedia.org/wiki/Phoenix_(compiler_framework)
I guess Phoenixey/LLVM type stuff is probably the way the winds were blowing in the compiler community at large. It's interesting how a lot of things that used to seem impossible are now in multiple software packages.
You figure that once MS is rolling out a compiler technology in a big way, it can't get much more mainstream than that.
I still don't totally understand why it was important for MS to push into JIT-compiled bytecode on Windows. From the end-user's standpoint, it just makes software slower.
It doesn’t always makes software slower.
Not all software is CPU bound, a lot is IO bound, and .NET framework implements event-based asynchronous I/O since version 1.0.
Probably the same one that caused the issues with Longhorn.
Now we have UWP with .NET Native, which is creating an OO ABI similar to Longhorn ideas.
Like most IDE's, it is a mediocre text editor with a bunch of compelling (for certain workflows) tooling for project and build management, debugger, etc. Plus usable introspection. As a text editor though, a solid C+ at best.
Is VS Code someone doing something radically different?
Completely open source, rich plugin/extension community. Pretty much has become the editor of choice if you're working on node or go... more than decent with other platforms, and as a general editor. There are extensions to improve workflows, but all optional extensions.
I have git history, git lense, eslint, docker, c# (works for .net core), go, jest, npm, npm intellisense, yandex-translate (makes vscode worthwhile by itself), and a couple others.
I don't think I can go back... having the treeview, git integration, integrated console, it's all just way awesome to say the least.
Sure, Visual Studio is a much much bigger challenge to make compatible. But come on, they've had over a decade during which it was obvious it should be 64bit compatible! A decade!
During the same decade-long timeframe they should have been working on lifting the 260 char path limit, another bug they "wontfix".
My guess is that they've had really strong product management - they really prioritize those snazzy features and releases, but aren't allowed to spend any time on the technical debt. (And, seriously, they've had a decade ...)
[0] https://blogs.msdn.microsoft.com/dotnet/2016/08/02/announcin...
As I recall, this was marked "wontfix" in 2013: https://visualstudio.uservoice.com/forums/121579-visual-stud...
It's been _possible_ using the NT Unicode APIs since Windows 2000: https://msdn.microsoft.com/en-us/library/930f87yf.aspx
But other common first-party windows development tools can still have the problem: https://github.com/Microsoft/msbuild/issues/53
Was really happy to see it was finally fixed in .Net and the Anniversary update, and long, long overdue.
- 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).
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.
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?
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.
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.
It's an incorrect yet popular assumption on the internet.
64 bits pointers take more space, which affects caching => Slower
64 bits architectures have more registers and instructions, and it removes the need to have an intermediate 32to64bit abstraction layer from the OS => Faster.
Overall, the side effects are extremely complex.
Moving an application from 32 to 64 bits is as likely to be 1% faster as to be 1% slower.
About the only real benefit is that the system can handle more RAM (which of course is a good thing). For some applications that are very, very memory-hungry, this can improve performance dramatically, because the program no longer needs to juggle all that data and can just keep it in RAM.
This only applies to running a 64-bit kernel vs a 32-bit kernel; running a 32-bit process on a 64-bit kernel will incur the same page table cost as a 64-bit process.
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.
And no, as any C++ developer will tell you, the answer is not to move to a souped-up text editor (Visual Studio Code).
https://blogs.msdn.microsoft.com/ricom/2016/01/04/64-bit-vis...
...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...