Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

blogs.msdn.microsoft.com

Post reply on HN
Print view View original

61–70 of 159 posts

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

#61

Post by the-dude »

whitefish wrote: post #23
marktucker wrote: post #11

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.

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?

Oh noes. You need lots more to run OSX El Capitan as I found out after acquiring a second-hand iMac. It was unusable at 1GB.

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

#62

Post by mrich »

snnn wrote: post #32

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

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.

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

#63

Post by brynjolf »

bicubic wrote: post #57
codeflo wrote: post #49

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 ca…

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.

Visual Studio Code is slow in comparison to VS. It has way less features. I hope this is not the path they take.

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

#64

Post by rrdharan »

sp332 wrote: post #28

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.

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-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.

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

#65

Post by hashhar »

ryandrake wrote: post #56
hashhar wrote: post #44

Earlier quoted context omitted.

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 1…

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.

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

#66

Post by kabdib »

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).

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

#67

Post by hashhar »

ryandrake wrote: post #56
hashhar wrote: post #44

Earlier quoted context omitted.

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 1…

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.

If you could give me a brief list of what features you expect from such a tool I'll be happy to take it up as a project and release it.

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

#69

Post by scott_s »

ygra wrote: post #3
davrosthedalek wrote: post #2

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?

Rico responded to that question on one Reddit discussion about the issue once: 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 »perfo…

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.)

Post reply on HN