Microsoft Phases Out 32-Bit Support for Windows 10
Click here to post a comment for Microsoft Phases Out 32-Bit Support for Windows 10 on our message forum
wavetrex
Astyanax
Richard Nutman
Astyanax
Richard Nutman
Using more registers does not slow the cpu down or create more heat. It allows the compiler to produce more efficient and simpler/faster code.
I've just given you 3 reasons why 64bit code is superior. There are several more.
Alessio1989
Having more registers doesn't automatically mean better performance on the same peace of code. For that kinda code register renaming is a better solution. WOW64 subsystem overhead is typically meaningless, upcasting a couple of pointers for some content switches is not an issue at all. Don't forget also that more registers also mean more complex pipeline while less registers also mean less bits for source and destination register in the binary for the same assembly, which means shorter binary, which mean shorter source area in an executable which means less cache miss probabilities. If you do not need at all to take advantage of x64 instruction set, 32-bit pointers as Astyanax pointed means also shorter data records, which means better usage of cache.
Richard Nutman
https://www.viva64.com/en/a/0030/
You're right it doesn't automatically mean better performance. But complex loops with lots of variables invariably will.
You don't get access to register renaming, that's something the CPU does internally.
It's the programming interface that is restricted to 8 registers in 32bit mode. Nothing you can do about this.
The complexity of the pipeline doesn't change either. It's the same hardware running the code, you're just not using some parts of it.
Not using some registers doesn't change the size of the executable.
Here is a link with more detail;
Alessio1989
alanm
Surprised not sooner. Even Linux distros have dropped 32-bit support already.
Richard Nutman
Yxskaft
Richard Nutman
Here is another example;
https://godbolt.org/z/2psR3Y
On the left is some sample matrix multiply code.
The middle pane is compiled using gcc to 64bit code.
The right hand pane is compiled using gcc to 32bit code.
The 64bit code is 134 lines of instructions.
The 32bit code is 168 lines of instructions. You can see a lot more push/pop instructions.
The main loop at L24 has 3 more instructions in the 32bit code.
mbk1969
Alessio1989
Richard Nutman
https://ibb.co/XknfHwX
This is one example anyway, there are loads more applications still running in 32bit mode.
It's an extremely simple example that shows function calls are way more efficient on x64. As code complexity increases, the 64bit app with more registers will handle that complexity more efficiently.
Mov instructions are extremely cheap, they don't even take time to execute if it's register to register. Besides which there wouldn't be more move instructions anyway.
The alignment requirements for SIMD are the same in 32bit and 64bit. In fact since 64bit guarantees SSE2 which has more unaligned load functions, you get more flexibility with alignment with 64bit code.
It's only more memory if you're storing loads of them, and the link I gave shows workarounds. You can just use 32bit indexing instead of storing pointers if it results in massive increase in memory. Most of the time pointers reside in registers or local variables and then their size is irrelevant.
Incorrect. Open task manager, any process with a (32) after it is 32bit code.
See here;
Alessio1989
Your IDE is using the 32-bit compiler (inside Hostx86 folder I guess) for 64-bit targeting. For using 64-bit compiler you need to launch it from Hostx64 and then your target platform folder. https://docs.microsoft.com/en-us/cpp/build/how-to-enable-a-64-bit-visual-cpp-toolset-on-the-command-line?view=vs-2019
Yes that sucks. Visual Studio completely ported to 64-bit would be really nice. At least the debugger is an 64-bit out-of-process program now: https://devblogs.microsoft.com/cppblog/out-of-process-debugger-for-c-in-visual-studio-2019/
Btw mov/pop/push should run identical iif the data are already in register or in stack. mov from/to main memory is the critical part.
And yes, SSE2/../4.2 alignment requirements are the same for 32 and 64-bit x86 code, but most (all?) x86 compilers will try to use and generate SIMD code, especially with /O2 when targeting 64-bit while that's not true when targeting 32-bit. Abusing SIMD may results in slower code.
But again the 64-bit compiled code is generally faster (especially due better calling conventions and modern compilers), but not always. And again the WOW64 performance coast is meaningless on modern hardware.
mbk1969
Richard Nutman
https://www.agner.org/optimize/instruction_tables.pdf
The point being if the compiler picks the right register for parameters to functions it is not replacing a push and pop with a mov, it doesn't need to do the mov at all!
No I'm targetting 64bit builds. The compiler is 32bit but can output code for 32 or 64bit targets.
It's good that they have a 64bit compiler, but that's not what is triggered by VS IDE it seems.
No, push and pop have higher latency and less throughput than MOV's
mbk1969
Also note that using .Net Framework the same .Net binary executable can be executed both on 32- and 64-bit environment. 😛
Alessio1989