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

21–30 of 159 posts

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

#21

Post by masklinn »

wolfgke wrote: post #12
masklinn wrote: post #5

Earlier quoted context omitted.

> I might be wrong, but aren't there much more registers available in 64 bit mode on intel? It's not "intel", it's x86. x86_64 has twice the number of registers.

> x86_64 has twice the number of registers The "typical ALU instructions" as add, cmp etc. can now encode 16 registers instead of 8. But the FPU stack still has 8 entries to encode and there are also still only has 8 MMX registers in 64 bit mode (they overlay the FPU stack as you surely know). On the other hand with AVX-512 there will be 32 xmm/ymm/zmm registers available instead of 8 in 32 bit mode (4 times). UPDATE…

True, I should have said GPR rather than registers.

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

#22

Post by wolfgke »

sherincall wrote: post #9

I really wish MSFT would support the x32 ABI[0]. While having a single amd64 ABI, compared to 6-7 active in the x86 days, has its advantages, MSFT already threw it away with vectorcall. And x32 is arguable more useful than vectorcall. [0]: https://en.wikipedia.org/wiki/X32_ABI

An ABI for amd64 was consciously developed independently by the gcc developers and Microsoft. Microsoft did "the obvious thing" and extended __fastcall to define their ABI.

Here are links about this topic:

> http://stackoverflow.com/a/35619528/497193

> http://stackoverflow.com/a/4438515/497193

> http://stackoverflow.com/a/35621290/497193

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

#23

Post by whitefish »

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?

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

#24

Post by BinaryIdiot »

I remember his original post back in 2009 and being very unsatisfied.

I wanted the 64-bit transition only so I could properly use my tools at work (used to work in a .Net shop). We had resharper and several other plugins that ran in the same Visual Studio process as everything else and it was fairly common to hit the memory limit of a 32-bit process and Visual Studio would essentially die until it was killed and restarted.

Sure, you can say "stop using those tools" or "they should have written them better". But at the time I was required to use most of them (it wasn't only Resharper though Resharper was pretty nice).

Today I don't have this problem anymore. But I think because of that type of issue it would still likely be worth it. Honestly I feel like they could optimize Visual Studio at the same time; it has a ton of capability but it's also incredibly large and, from my understanding, carries a TON of legacy code and resources throughout.

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

#25

Post by sp332 »

sherincall wrote: post #9

I really wish MSFT would support the x32 ABI[0]. While having a single amd64 ABI, compared to 6-7 active in the x86 days, has its advantages, MSFT already threw it away with vectorcall. And x32 is arguable more useful than vectorcall. [0]: https://en.wikipedia.org/wiki/X32_ABI

I already have 32-bit and 64-bit copies of all the libraries on my computer. I'm really not looking forward to having a third copy lying around.

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

#26

Post by Splines »

taspeotis wrote: post #14

Run devenv /safemode to load the IDE without third party extensions (think ReSharper) and the thing flies. It's not Microsoft's code that's the problem.

Yeah - my work instance of VS is sluggish as hell, and I sometimes load up a separate instance with toy problems to prototype ideas and it's practically as light as notepad.

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

#27

Post by BinaryIdiot »

roel_v wrote: post #15
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.

Sure, but it does so much more than VC6 used to do. I mean, the intellisense is so good nowadays, the continuous compiling that essentially gives you on the fly 'compiler errors', ... I agree that it would probably be nice if those could be turned off, and the UI is sluggish, but VC6 was (apart from being fast) not much to write home about (compared to what we have now).

To be fair though parent was referring to VC6's start-up time compared to the current version's start-up time. Is it fair to expect continuous compilation or maybe even intenseness to slow down start-up? I'm not so sure.

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

#29

Post by whitefish »

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?

No. With 8 bit you had to execute multiple instructions to add two numbers. Same with 16 bit. This problem went away with 32 bit. Adding more bits beyond 32 does not bring proportional benefits because the numbers we deal with fit in 32 bit.

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

#30

Post by BinaryIdiot »

taspeotis wrote: post #14

Run devenv /safemode to load the IDE without third party extensions (think ReSharper) and the thing flies. It's not Microsoft's code that's the problem.

We...may have different definitions of "flies". Yes if you disable third party plugins then it should be fast at various points in its lifecycle. At the same time it's not really that fast when you have zero plugins installed...
Post reply on HN