Revisiting 64-bit-ness in Visual Studio and elsewhere (2015)
blogs.msdn.microsoft.com
Revisiting 64-bit-ness in Visual Studio and elsewhere (2015)
1–10 of 159 posts
Re: Revisiting 64-bit-ness in Visual Studio and elsewhere (2015)
#2I 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?
Re: Revisiting 64-bit-ness in Visual Studio and elsewhere (2015)
#3I 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?
Rico responded to that question on one Reddit discussion about the issue once: https://www.reddit.com/r/programming/comments/3zddyh/revisit...
In short, due to VS having an already large working set it hurts more to let it grow even larger than having more registers helps.
I also think that many people took his stance as »32 bit should enough for anybody and no one should move to 64 bit«, whereas it was more a »performance characteristics for different types of applications are very different and for Visual Studio it's a choice that will make things slower«. Admittedly, that doesn't appease the people who experience crashes, although extensions like ReSharper are often more wasteful with memory than the IDE itself and those could just as easy be put in a separate process. Although for JetBrains it's probably a marketing argument to push ReSharper users to Rider (which actually uses an out-of-process model and thus not have the problem).
Re: Revisiting 64-bit-ness in Visual Studio and elsewhere (2015)
#4>
In the immortal words of Sherman T. Potter: “Horse hucky!”
?
Re: Revisiting 64-bit-ness in Visual Studio and elsewhere (2015)
#5I 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.
Re: Revisiting 64-bit-ness in Visual Studio and elsewhere (2015)
#6> In the immortal words of Sherman T. Potter: “Horse hucky!” ?
Sherman T. Potter
> http://mash.wikia.com/wiki/Sherman_T._Potter
horse huckey:
> http://www.urbandictionary.com/define.php?term=horse%20hocke...
Colonel Potter curses (“Horse hucky!” is at the beginning):
Re: Revisiting 64-bit-ness in Visual Studio and elsewhere (2015)
#7I 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.
Re: Revisiting 64-bit-ness in Visual Studio and elsewhere (2015)
#8Hmm. We must all be a bunch of rubes for running 64-bit code in so many places these days.
Re: Revisiting 64-bit-ness in Visual Studio and elsewhere (2015)
#9I 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.
Re: Revisiting 64-bit-ness in Visual Studio and elsewhere (2015)
#10I 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.
Never mind that it was AMD that extended x86 to support 64 bit, while Intel was off chasing its own tail with Itanium.