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

81–90 of 159 posts

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

#81

Post by robert_foss »

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…

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.

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

#82

Post by masklinn »

kabdib wrote: post #66

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

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

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

#83

Post by tigershark »

robert_foss wrote: post #81
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…

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.

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

#84

Post by ovao »

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

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

#85

Post by wolfgke »

mschaef wrote: post #71
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?

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…

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

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

#86

Post by oblio »

mschaef wrote: post #59
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…

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

> 1 contrived example

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

#87

Post by masklinn »

wolfgke wrote: post #51
will_hughes wrote: post #48

Earlier quoted context omitted.

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?

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

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

#88

Post by daigoba66 »

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 a wonderful text editor. But it's far from being a full-featured IDE.

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

#89

Post by mtdewcmu »

hashhar wrote: post #75
bicubic wrote: post #57

Earlier quoted context omitted.

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.

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.

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

#90

Post by rikkus »

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.

Post reply on HN