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

111–120 of 159 posts

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

#111

Post by CountSessine »

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 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 but 64-bit could reach +800 cycles.

This only applies to running a 64-bit kernel vs a 32-bit kernel; running a 32-bit process on a 64-bit kernel will incur the same page table cost as a 64-bit process.

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

#112

Post by wtetzner »

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.

There are already large chunks of managed code in VS. It might be that they are pushing to fully convert to managed code for other reasons, and as a side benefit they get 64-bit support for "free".

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

#113

Post by hashhar »

floatboth wrote: post #97
hashhar wrote: post #67

Earlier quoted context omitted.

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

Thanks for the recommendation. Exactly what the parent commenter was asking for.

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

#114

Post by mtdewcmu »

wtetzner wrote: post #112
mtdewcmu wrote: post #89

Earlier quoted context omitted.

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.

There are already large chunks of managed code in VS. It might be that they are pushing to fully convert to managed code for other reasons, and as a side benefit they get 64-bit support for "free".

Probably the parts that are still in native code include stuff that is performance-sensitive, like the guts of the compilers. It's probably intricate and finely-tuned.

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

#115

Post by wolfgke »

mschaef wrote: post #107
wolfgke wrote: post #85

Earlier quoted context omitted.

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

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

Of course this is true. You wrote further above:

> In a 16-bit address space (64K), you hit the 16-bit limit _all the time_.

I wanted to outline that whether this is a problem or not depends a lot on the concrete 16 bit architecture.

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

#116

Post by dekhn »

pacaro wrote: post #109
dekhn wrote: post #54

Earlier quoted context omitted.

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

the "exotic" machine at the time was a Digital Alpha (64 bit! In 1995) that had 64MB IIRC. It did fly. The solaris machines we used took 20 minuts to boot and another 1 minute to open a shell.

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

#117

Post by dosshell »

ploxiln wrote: post #100
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…

It was fixed in .net 4.6.2 [0]

[0] https://blogs.msdn.microsoft.com/dotnet/2016/08/02/announcin...

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

#118

Post by [deleted] »

jcranmer wrote: post #79
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 extr…

[deleted]

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

#119

Post by tigershark »

CountSessine wrote: post #111
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 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)

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

#120

Post by pjmlp »

mtdewcmu wrote: post #114
wtetzner wrote: post #112

Earlier quoted context omitted.

There are already large chunks of managed code in VS. It might be that they are pushing to fully convert to managed code for other reasons, and as a side benefit they get 64-bit support for "free".

Probably the parts that are still in native code include stuff that is performance-sensitive, like the guts of the compilers. It's probably intricate and finely-tuned.

Only C++ ones, the main goal of Roslyn was to bootstrap C# and VB.NET compilers and get rid of their former C++ implementation.

Now with Roslyn and .NET Native, they are planning to increasingly move more runtime stuff into C#.

.NET Native backend is of course shared with Visual C++, aka C2, a kind of Microsoft's own LLVM-like approach.

Post reply on HN