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

121–130 of 159 posts

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

#121

Post by Arnavion »

dosshell wrote: post #117
ploxiln wrote: post #100

Earlier quoted context omitted.

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…

It was fixed in .net 4.6.2 [0] [0] https://blogs.msdn.microsoft.com/dotnet/2016/08/02/announcin...

It was fixed in Windows :) Any application can add a manifest entry to enable long paths. The .Net change is because .Net needed to expose / add support for it in addition to the base OS supporting it.

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

#122

Post by pjmlp »

mtdewcmu wrote: post #89
hashhar wrote: post #75

Earlier quoted context omitted.

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.

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

Probably the same one that caused the issues with Longhorn.

Now we have UWP with .NET Native, which is creating an OO ABI similar to Longhorn ideas.

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

#123

Post by CountSessine »

tigershark wrote: post #119
CountSessine wrote: post #111

Earlier quoted context omitted.

Because no one else has mentioned it, paging is more expensive in 64-bit. In 64-bit, the kernel uses a 3 or 4 level page table requiring 3 or 4 SDRAM accesses on a TLB miss. 32-bit kernels can get away with 2 SDRAM accesses (PDE+PTE) if they're doing 32-to-32 translation. On a ~3GHz CPU, each uncached SDRAM access will cost the CPU about 200 cycles which means a worst-case 32-bit scenario would be about 400 cycles bu…

Exactly, and I seriously doubt that in 2017 anyone is using a 32 bit OS with visual studio (I had to endure it in 2015 at work and I know very well what it means)

Agreed. And, while I have no evidence of this, my intuition is that the extra GPRs you get in 64-bit more than makes up for any minuscule system-wide performance hit 64-bit long-mode paging imposes.

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

#124

Post by moogly »

I don't see the point of this article. The VS team has moved more and more stuff out-of-process. VS 2015 can easily use more than 4 GB (if you're working in medium to large solutions), but it's divided up across 3-4 main processes. MSBuild processes (normally 1 per thread) are also staying around for 15 minutes now, so they can be reused.

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

#125

Post by ploxiln »

dosshell wrote: post #117
ploxiln wrote: post #100

Earlier quoted context omitted.

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…

It was fixed in .net 4.6.2 [0] [0] https://blogs.msdn.microsoft.com/dotnet/2016/08/02/announcin...

Wow, fixed in 2016.

As I recall, this was marked "wontfix" in 2013: https://visualstudio.uservoice.com/forums/121579-visual-stud...

It's been _possible_ using the NT Unicode APIs since Windows 2000: https://msdn.microsoft.com/en-us/library/930f87yf.aspx

But other common first-party windows development tools can still have the problem: https://github.com/Microsoft/msbuild/issues/53

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

#126

Post by TillE »

tpolm wrote: post #102

"The one who wants - seeks ways, who does not want - seeks a reason"

That's pretty apt. There are always legitimate reasons why doing something is difficult and imperfect, but there's a really clear future here. It's absurd to think that Visual Studio will remain 32-bit in 10 or 20 years' time.

And no, as any C++ developer will tell you, the answer is not to move to a souped-up text editor (Visual Studio Code).

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

#127

Post by syncsynchalt »

loarabia wrote: post #50
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?

I think he touched on this a little in a follow-up he did: https://blogs.msdn.microsoft.com/ricom/2016/01/04/64-bit-vis... My interpretation of the shift from So the question might be are there any surprising workarounds in the code because you're only dealing with 32 bit code where if you had 64 bits you could write some more elegant solution.

It's not exactly what you're asking for, but you'll run into a big one in about two decades.

The only other example I can think of is the general "problem" of large databases. There's just a lot more paging and churn that has to happen in a 32-bit address space. Many NoSQL databases in particular have a memory model of mmap'ing an entire database, which runs into a hard limit on 32-bit address space.

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

#128

Post by krylon »

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…

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

Let alone USB. During my training, there were lots of desktops running Windows NT 4.0, which did not know USB. By the time I had already become so used to copying data back and forth with a USB thumb drive (even though back then their capacity was still measured in megabytes), that it became fairly annoying to walk up to some computer, plug in the thumb drive, then realize this machine is running NT 4.0, not Windows 2000, cursing, then looking for another way to get some piece of data on that computer: Usually put it on some other machine copy it over the network.

Ah, those were the days... ;-)

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

#129

Post by alkonaut »

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.

The big perf drop in VS was between 2013 and 2015 when Roslyn was introduced (not sure if that's the reason though). It has improved somewhat in 2017 but I still find 2013 to be significantly faster than 2017.

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

#130

Post by krylon »

user5994461 wrote: post #92
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 ap…

This has been my experience, too, mostly. I ran both a 32-bit and a 64-bit Linux desktop on an Athlon64, both for several months, and I did not notice a difference in performance.

About the only real benefit is that the system can handle more RAM (which of course is a good thing). For some applications that are very, very memory-hungry, this can improve performance dramatically, because the program no longer needs to juggle all that data and can just keep it in RAM.

Post reply on HN