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

31–40 of 159 posts

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

#31

Post by wolfgke »

hrydgard wrote: post #20
wolfgke wrote: post #12

Earlier quoted context omitted.

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

> The FPU stack is legacy and is barely used anymore

I know that if you implement an algorithm via SSE/AVX it typically is much faster than if you use the FPU. But I still believe that the FPU has its uses: For example it also supports 80 bit precision floating point numbers, while SSE/AVX only support 32 or 64 bit ones. There are applications where this capability can be quite useful. This is one reason why the FPU is still supported (and sometimes used) in 64 bit mode.

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

#33

Post by orcy »

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

We still build some stuff with VS2005 and it feels very fast and responsive while having everything I usually need in ide. The only thing it missing is modern C++ compiler.

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

#34

Post by ygra »

BinaryIdiot wrote: post #24

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

I guess his original point was that while moving to 64 bit would help the few users who actually hit memory allocation limits, it would also be a monumental effort for a project the size of Visual Studio to do so, including out-of-process support for 32-bit extensions to maintain compatibility, probably rethinking designers and debugging along the way. And all that to make things actually slower and taking more memory for everyone. His argument wasn't entirely »Stop using those tools while we do nothing at all«. It was »They should have done the right thing, but we'll also work towards making Visual Studio take less memory«. Especially considering that not leading everything you might eventually ever need at once in the beginning has probably a much smaller compatibility impact than upgrading significant parts of the IDE.

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

#36

Post by oblio »

whitefish wrote: post #23
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?

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. It is big because your needs are big".

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

#37

Post by snnn »

ygra wrote: post #35
snnn wrote: post #32

Right now, I'm fighting with: "fatal error LNK1248: image size (1004CB720) exceeds maximum allowable size (FFFFFFFF)" :-(

That has nothing to do with Visual Studio, though. There is a 64-bit linker and you can use it.

I already set toolset to x64. It's 64 bits cl.exe running.

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

#38

Post by wolfgke »

whitefish wrote: post #29
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.

> No. With 8 bit you had to execute multiple instructions to add two numbers. Same with 16 bit.

Wrong (for x86-16 vs. x86-32). Just use an operand-size size override prefix (0x66) with your 16 bit real mode ALU (in this case 'add') instruction to make it a 32 bit ALU instruction. Works from 80386 on, where the 32 bit registers were introduced.

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

#40

Post by loganmhb »

eb0la wrote: post #17

I 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

When reading about Elasticsearch I was fascinated to learn that the JVM can often use 32-bit object pointers to address about 32GB of RAM when running in 64-bit mode: https://wiki.openjdk.java.net/display/HotSpot/CompressedOops
Post reply on HN