Changing many projects from AnyCPU to x64
-
Previously, our software had to be created for both 32bit and 64bit Windows. Now, product management decided that we do not need to support 32bit Windows anymore (that's great with regard to third party SDKs and drivers). In almost all of our some 200 projects, the DEBUG and RELEASE configurations have the "Platform target" of "Any CPU" only (only some wrappers of third party components are specialized). Of course, the software will run on 64bit systems with such settings. But compiling for 64bit only could allow for more compiler optimizations (or am I mistaken?), so I'd prefer to create 64bit executables. As shown in How do I specify the platform for MSBuild? - Stack Overflow[^] , there is no possibility to simply add a parameter to the msbuild command line, instead every project has to be changed... What's the easiest way to do so? Or do I not need to care because there's no advantage in doing so? Note: we use C# with Visual Studio Professional 2015 Version 14.0.25425.01 Update 3.
Oh sanctissimi Wilhelmus, Theodorus, et Fredericus!
-
Previously, our software had to be created for both 32bit and 64bit Windows. Now, product management decided that we do not need to support 32bit Windows anymore (that's great with regard to third party SDKs and drivers). In almost all of our some 200 projects, the DEBUG and RELEASE configurations have the "Platform target" of "Any CPU" only (only some wrappers of third party components are specialized). Of course, the software will run on 64bit systems with such settings. But compiling for 64bit only could allow for more compiler optimizations (or am I mistaken?), so I'd prefer to create 64bit executables. As shown in How do I specify the platform for MSBuild? - Stack Overflow[^] , there is no possibility to simply add a parameter to the msbuild command line, instead every project has to be changed... What's the easiest way to do so? Or do I not need to care because there's no advantage in doing so? Note: we use C# with Visual Studio Professional 2015 Version 14.0.25425.01 Update 3.
Oh sanctissimi Wilhelmus, Theodorus, et Fredericus!
One way to do that is to write an app to modify the .csproj files: they are XML, and contain the Platform:
AnyCPU
It wouldn't take much to knock up a quick app to convert all 200.
Sent from my Amstrad PC 1640 Never throw anything away, Griff Bad command or file name. Bad, bad command! Sit! Stay! Staaaay... AntiTwitter: @DalekDave is now a follower!
-
Previously, our software had to be created for both 32bit and 64bit Windows. Now, product management decided that we do not need to support 32bit Windows anymore (that's great with regard to third party SDKs and drivers). In almost all of our some 200 projects, the DEBUG and RELEASE configurations have the "Platform target" of "Any CPU" only (only some wrappers of third party components are specialized). Of course, the software will run on 64bit systems with such settings. But compiling for 64bit only could allow for more compiler optimizations (or am I mistaken?), so I'd prefer to create 64bit executables. As shown in How do I specify the platform for MSBuild? - Stack Overflow[^] , there is no possibility to simply add a parameter to the msbuild command line, instead every project has to be changed... What's the easiest way to do so? Or do I not need to care because there's no advantage in doing so? Note: we use C# with Visual Studio Professional 2015 Version 14.0.25425.01 Update 3.
Oh sanctissimi Wilhelmus, Theodorus, et Fredericus!
Bernhard Hiller wrote:
But compiling for 64bit only could allow for more compiler optimizations (or am I mistaken?), so I'd prefer to create 64bit executables.
Not really, the compiler doesn't do anything special, it just sets that flag on the binary (which can be modified later, by the way). What matters is the bitness at which the program actually runs. To the C# compiler, "optimization" means simple things such as using fewer temporary variables and branching directly on a condition instead of constructing a boolean out of it and then testing it, that sort of thing. There are various optimizations that *you* can do though: - Drop 32bit versions of dependencies and drop the release that uses them. Sounds like that's the plan. - Write code that explicitly assumes pointers are 8 bytes (doesn't come up a lot in C# obviously, but you can do it). - In 32bit mode, FP math gets done with x87 instructions, occasionally this required some workarounds to deal with 80bit/64bit precision mismatches, all of that nonsense can be removed. Most projects didn't bother with this in the first place. - Boldly using System.Numerics.Vectors all over the place, which is fast (well, *some* parts of it are fast, definitely double check) in 64bit mode but worse than pointless in 32bit mode. - Using things from System.Runtime.Intrinsics with X64 in the name, such as System.Runtime.Intrinsics.X86.Sse.X64, without checking `IsSupported` and without fallback.
-
Bernhard Hiller wrote:
But compiling for 64bit only could allow for more compiler optimizations (or am I mistaken?), so I'd prefer to create 64bit executables.
Not really, the compiler doesn't do anything special, it just sets that flag on the binary (which can be modified later, by the way). What matters is the bitness at which the program actually runs. To the C# compiler, "optimization" means simple things such as using fewer temporary variables and branching directly on a condition instead of constructing a boolean out of it and then testing it, that sort of thing. There are various optimizations that *you* can do though: - Drop 32bit versions of dependencies and drop the release that uses them. Sounds like that's the plan. - Write code that explicitly assumes pointers are 8 bytes (doesn't come up a lot in C# obviously, but you can do it). - In 32bit mode, FP math gets done with x87 instructions, occasionally this required some workarounds to deal with 80bit/64bit precision mismatches, all of that nonsense can be removed. Most projects didn't bother with this in the first place. - Boldly using System.Numerics.Vectors all over the place, which is fast (well, *some* parts of it are fast, definitely double check) in 64bit mode but worse than pointless in 32bit mode. - Using things from System.Runtime.Intrinsics with X64 in the name, such as System.Runtime.Intrinsics.X86.Sse.X64, without checking `IsSupported` and without fallback.
Thanks for that information. That means then that I do not need to change any settings, as I won't get any performance improvements when compiling to x64 instead of AnyCPU, except for those special cases you showed (getting rid of those 32bit dependencies is the most important point for me).
Oh sanctissimi Wilhelmus, Theodorus, et Fredericus!
-
Previously, our software had to be created for both 32bit and 64bit Windows. Now, product management decided that we do not need to support 32bit Windows anymore (that's great with regard to third party SDKs and drivers). In almost all of our some 200 projects, the DEBUG and RELEASE configurations have the "Platform target" of "Any CPU" only (only some wrappers of third party components are specialized). Of course, the software will run on 64bit systems with such settings. But compiling for 64bit only could allow for more compiler optimizations (or am I mistaken?), so I'd prefer to create 64bit executables. As shown in How do I specify the platform for MSBuild? - Stack Overflow[^] , there is no possibility to simply add a parameter to the msbuild command line, instead every project has to be changed... What's the easiest way to do so? Or do I not need to care because there's no advantage in doing so? Note: we use C# with Visual Studio Professional 2015 Version 14.0.25425.01 Update 3.
Oh sanctissimi Wilhelmus, Theodorus, et Fredericus!
I read up on it last year, because I have a 32bit Win Forms project and needed to support 64bit Win10. From what I read, compiling with X64 just creates a giant bloated program that consumes tons of memory. Using X32 creates a smaller program that is more efficient and compact. So I opted for Any CPU and it works fine on both Win7 32 bit OS, Win10 64 bit OS. Of course some NuGet libraries gave me issues in which I had to detect the OS and load the correct version. Several examples given was Office 32 vs Office 64, and why Visual Studio is 32 bit. Suppose it could be debated again.
If it ain't broke don't fix it Discover my world at jkirkerx.com
-
Previously, our software had to be created for both 32bit and 64bit Windows. Now, product management decided that we do not need to support 32bit Windows anymore (that's great with regard to third party SDKs and drivers). In almost all of our some 200 projects, the DEBUG and RELEASE configurations have the "Platform target" of "Any CPU" only (only some wrappers of third party components are specialized). Of course, the software will run on 64bit systems with such settings. But compiling for 64bit only could allow for more compiler optimizations (or am I mistaken?), so I'd prefer to create 64bit executables. As shown in How do I specify the platform for MSBuild? - Stack Overflow[^] , there is no possibility to simply add a parameter to the msbuild command line, instead every project has to be changed... What's the easiest way to do so? Or do I not need to care because there's no advantage in doing so? Note: we use C# with Visual Studio Professional 2015 Version 14.0.25425.01 Update 3.
Oh sanctissimi Wilhelmus, Theodorus, et Fredericus!
-
Maybe the question you should really be asking is, "what improvements will (in performance, efficiency etc.) will be seen by switching to x64?". Since 32 bit code will run fine on 64 bit systems it is important to change for the right reasons.
Exactly. Compilers do optimize - even the first Fortran compiler described by Backhus did. Now I am in a situation where 32bit support can be removed. Consequently, the compiler could use instructions available on 64bit processors which are not available on 32bit processors. I do not know what to expect here in detail - but I think it is adequate to expect some possibilities. On the other hand, as others pointed out, the intermediate language may not have so much differences, because it is interpreted by the underlying .Net Framework (which might be optimized for the processor).
Oh sanctissimi Wilhelmus, Theodorus, et Fredericus!
-
Exactly. Compilers do optimize - even the first Fortran compiler described by Backhus did. Now I am in a situation where 32bit support can be removed. Consequently, the compiler could use instructions available on 64bit processors which are not available on 32bit processors. I do not know what to expect here in detail - but I think it is adequate to expect some possibilities. On the other hand, as others pointed out, the intermediate language may not have so much differences, because it is interpreted by the underlying .Net Framework (which might be optimized for the processor).
Oh sanctissimi Wilhelmus, Theodorus, et Fredericus!
The 64bit and 32bit JIT engines are (except in .NET Core 2 and 3) [diffent](https://devblogs.microsoft.com/dotnet/ryujit-the-next-generation-jit-compiler-for-net/), even the old 64bit JIT was already different, with the 64bit versions being better - mostly not thanks to 64bit instructions but because it's a better JIT engine. RyuJIT especially has seen many performance enhancements in recent years, the old 32bit legacy engine (the one you get in non-Core) AFAIK is just its crummy old self without anything fancy like [devirtualization](https://www.infoq.com/news/2017/12/Devirtualization/) and [various small tricks](https://devblogs.microsoft.com/dotnet/ryujit-just-in-time-compiler-optimization-enhancements/). Even the old 64bit JIT engine already had [better array bounds check elimination](https://blogs.msdn.microsoft.com/clrcodegeneration/2009/08/13/array-bounds-check-elimination-in-the-clr/) and inlining (couldn't find a good source). On the other hand, the 64bit versions are also working against the inherent disadvantage of wasting double the space on pointers, and C# is an especially pointer-heavy language. So it's not a clear cut win either way and you can easily tune a benchmark to justify either conclusion.
-
The 64bit and 32bit JIT engines are (except in .NET Core 2 and 3) [diffent](https://devblogs.microsoft.com/dotnet/ryujit-the-next-generation-jit-compiler-for-net/), even the old 64bit JIT was already different, with the 64bit versions being better - mostly not thanks to 64bit instructions but because it's a better JIT engine. RyuJIT especially has seen many performance enhancements in recent years, the old 32bit legacy engine (the one you get in non-Core) AFAIK is just its crummy old self without anything fancy like [devirtualization](https://www.infoq.com/news/2017/12/Devirtualization/) and [various small tricks](https://devblogs.microsoft.com/dotnet/ryujit-just-in-time-compiler-optimization-enhancements/). Even the old 64bit JIT engine already had [better array bounds check elimination](https://blogs.msdn.microsoft.com/clrcodegeneration/2009/08/13/array-bounds-check-elimination-in-the-clr/) and inlining (couldn't find a good source). On the other hand, the 64bit versions are also working against the inherent disadvantage of wasting double the space on pointers, and C# is an especially pointer-heavy language. So it's not a clear cut win either way and you can easily tune a benchmark to justify either conclusion.
Thanks for the information. The memory consumption by the large pointers is not such a big issue - our most important application uses some 500 MB, in a device with 4 GB. But (heat production by) CPU usage is important: typically 50% CPU load, and that small box can get very warm.
Oh sanctissimi Wilhelmus, Theodorus, et Fredericus!
-
Previously, our software had to be created for both 32bit and 64bit Windows. Now, product management decided that we do not need to support 32bit Windows anymore (that's great with regard to third party SDKs and drivers). In almost all of our some 200 projects, the DEBUG and RELEASE configurations have the "Platform target" of "Any CPU" only (only some wrappers of third party components are specialized). Of course, the software will run on 64bit systems with such settings. But compiling for 64bit only could allow for more compiler optimizations (or am I mistaken?), so I'd prefer to create 64bit executables. As shown in How do I specify the platform for MSBuild? - Stack Overflow[^] , there is no possibility to simply add a parameter to the msbuild command line, instead every project has to be changed... What's the easiest way to do so? Or do I not need to care because there's no advantage in doing so? Note: we use C# with Visual Studio Professional 2015 Version 14.0.25425.01 Update 3.
Oh sanctissimi Wilhelmus, Theodorus, et Fredericus!
