Live data from Hacker News

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

blogs.msdn.microsoft.com

101–110 of 159 posts

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

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

[deleted]

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

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

The editor is noticeably laggy on my Xubuntu VM. Emacs/vim are speedy, as is VS on the host.

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

#107
post #85
post #71

Earlier quoted context omitted.

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…

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

This only works in real mode, where the segment is shifted and directly added to the offset. In protected mode, it goes through a selector table. This can be made to work too, but it requires tiled allocations of segments with known delta between each segment. This is what __ahincr was about, if you remember it from the Win16 days.

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

#108
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, because the steps are exponential. You can sit down and type your way through 64k. If this was an argument by induction, then 1 bit would have been fine too.

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

#109
post #54

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?

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

Back when EMACS stood for Eight Megs And Constantly Swapping.

It's salutary to consider that the memory for a reasonably spec'd machine a little over 20 years ago is now a rounding error

I remember at about that time having 80MiB of RAM: a) my machine flew, and b) plenty of people would ask why I needed so much

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

#110

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?

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.

Forgive the nitpick, but it is "make do", if only because "make due" reads very awkwardly in British English where "due" is pronounced as if it is spelled with a U and an E, not as if it is spelled with two O's
Post reply on HN