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

71–80 of 159 posts

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

#71

Post by mschaef »

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

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

#72

Post by snnn »

mrich wrote: post #62
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.

Thanks for your help.

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

#73

Post by chillee »

brynjolf wrote: post #63
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.

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

It's not slower than VS. It's just not an IDE.

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

#74

Post by blauditore »

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?

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

#75

Post by hashhar »

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.

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.

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

#76

Post by intrasight »

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 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 When we have less, we make due with less. When we have more, we consume more. It's sort of like money.

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

#77

Post by mtdewcmu »

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…

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.

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

#78

Post by lsadam0 »

brynjolf wrote: post #63
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.

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.

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

#79

Post by jcranmer »

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…

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.

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

#80

Post by vvanders »

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…

Cache sizes are fixed to less things fit in L1/L2 than did before.
Post reply on HN