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

51–60 of 159 posts

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

#51

Post by wolfgke »

will_hughes wrote: post #48
loganmhb wrote: post #40

Earlier quoted context omitted.

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

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…

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

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

#52

Post by taude »

mtdewcmu wrote: post #7

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.

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

#54

Post by dekhn »

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?

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.

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

#56

Post by ryandrake »

hashhar wrote: post #44
whitefish wrote: post #23

Earlier quoted context omitted.

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?

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.

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

#57

Post by bicubic »

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.

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

#58

Post by [deleted] »

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…

[deleted]

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

#59

Post by mschaef »

oblio wrote: post #36
whitefish wrote: post #23

Earlier quoted context omitted.

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

If it takes 1008MB to seamlessly connect to a wireless network, something is clearly wrong.

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

#60

Post by fsfod »

sherincall wrote: post #9

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

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

Post reply on HN