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.
Revisiting 64-bit-ness in Visual Studio and elsewhere (2015)
11–20 of 159 posts
Re: Revisiting 64-bit-ness in Visual Studio and elsewhere (2015)
#12I might be wrong, but aren't there much more registers available in 64 bit mode on intel? That potentially outweighs any memory increase because it can reduce cache pressure. Or is this mostly alleviated by register renaming and other tricks?
> 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: On the other hand in 64 bit mode there are only 2 segment registers available instead of 6 in 32 bit mode (OK, the 4 common ones were (IMHO unjustifiably, since there are some cool things that you can use them for if you know what you do) not used in modern 32 bit OSes (Windows NT, Linux), so they were left out).
TLDR: The multitude depends on the type of register that you consider.
Re: Revisiting 64-bit-ness in Visual Studio and elsewhere (2015)
#13I might be wrong, but aren't there much more registers available in 64 bit mode on intel? That potentially outweighs any memory increase because it can reduce cache pressure. Or is this mostly alleviated by register renaming and other tricks?
Turns out most programs don't really need that much register space. Some do, though, really depends on what you're running.
Re: Revisiting 64-bit-ness in Visual Studio and elsewhere (2015)
#14Run 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.
Re: Revisiting 64-bit-ness in Visual Studio and elsewhere (2015)
#15In 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).
Re: Revisiting 64-bit-ness in Visual Studio and elsewhere (2015)
#16Would 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?
Re: Revisiting 64-bit-ness in Visual Studio and elsewhere (2015)
#17I remember people favoring the use of their 32bit JVM instead of the 64-bit one for performance reasons but didn't wondered why.
Makes sense if you're running Java with -Xmx1024m
Re: Revisiting 64-bit-ness in Visual Studio and elsewhere (2015)
#18I only work on higher level languages like js and Python. Makes me realize how much I need to know about performance before I complain about IDEs.
Re: Revisiting 64-bit-ness in Visual Studio and elsewhere (2015)
#19Would 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?
More is always better. Four wheels is better than two; cars should have eight wheels.
Look at GUID partition tables. With MBR, we had to hobble along with only a byte to identify partition types. Now we have 128 bits. We can finally support more filesystem kinds now than there are atoms in the Sun, all in one system installation, and the bootloader just has to look at the GUID. A 32 bit "fourcc" partition label clearly wouldn't have been enough.
Re: Revisiting 64-bit-ness in Visual Studio and elsewhere (2015)
#20Earlier 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…
The FPU stack is only 8 entries in x86-64, yes, but the 128-bit SSE float/SIMD register set was indeed expanded to 16 entries, just like the GPRs (rax, rcx etc). The FPU stack is legacy and is barely used anymore, instead most floating point operations are done with SSE instructions.