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

91–100 of 159 posts

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

#91

Post by jasonkostempski »

lsadam0 wrote: post #78
brynjolf wrote: post #63

Earlier quoted context omitted.

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

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

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

#92

Post by user5994461 »

blauditore wrote: post #74

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…

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

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

#93

Post by user5994461 »

eb0la wrote: post #17

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

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.

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

#94

Post by lsadam0 »

jasonkostempski wrote: post #91
lsadam0 wrote: post #78

Earlier quoted context omitted.

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

VS Code does break off features into separate components. This is what I'm referring to when I say "build the experience I want".

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

#95

Post by detaro »

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…

Can't you just turn compressed object pointers off, or am I misunderstanding the issue?

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

#96

Post by floatboth »

Cyph0n wrote: post #41
oblio wrote: post #36

Earlier quoted context omitted.

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…

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)

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

#97

Post by floatboth »

hashhar wrote: post #67
ryandrake wrote: post #56

Earlier quoted context omitted.

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.

Don't reinvent collectd :)

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

#98

Post by floatboth »

whitefish wrote: post #29
oobey wrote: post #16

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?

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.

"the numbers we deal with fit in 32 bit"

Except when they don't. Everyone already forgot tweet number 2147483648? :) https://techcrunch.com/2009/06/12/all-hell-may-break-loose-o...

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

#99

Post by floatboth »

eb0la wrote: post #17

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

HotSpot JVM uses compressed pointers by default on 64-bit anyway…

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

#100

Post by ploxiln »

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…

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

Post reply on HN