On 7 Apr 2015 at 9:38, Andrey Semashev wrote:
Does this mean that on Windows, if building Boost with
b2 stage
... on a x64 machine, we finally default produce 64 bit binaries not 32 bit ones?
If so, I take my hat off to whoever is responsible. Long overdue that fix.
Building 64-bit on Windows is not the preferred option for the vast majority of applications, for compatibility reasons.
I have no idea what this means. If it was ever true, it might have been a decade ago back when I was running a 64 bit version of Windows XP and even then it had surprisingly good driver support. So I'll claim even then it wasn't an issue for most a full ten years ago.
Typically only those that actually need gobs of memory (read: >1.5GB per app) get compiled for 64-bit. While these certainly exist, they're relatively rare (except in certain domains, perhaps).
Larger address space is not the only benefit of 64-bit x86. More registers (GPRs are also widened to 64 bits), mandatory SSE2, new addressing mode - all these features are very much useful even if you don't need large amounts of memory. In fact, there is no point in building 32-bit binaries nowdays, unless you desperately need compatibility with 32-bit only systems (read - more than a decade old).
Also, the Windows 7/8 memory allocator performs *far* better in x64. Indeed it increases its performance the more memory you allocate up to some fairly scary amounts, thanks to those gobs of address space. You also avoid WOW32 if you build native binaries. Plus you get extra security measures like address randomisation and better anti stack smashing. And even silly things like C++ member functions don't need parameter inverse repacking when transitioning between cdecl and thiscall, something which is stupidly inefficient in x86 MSVC for small functions with a lot of parameters.
Regarding MSVC defaults - I think there is a little misunderstanding here. There is no "default" from the compiler standpoint, it's just a matter of environment setup, which defines the compiler executable (cl.exe) that gets picked. The "default" (i.e. clean) environment is not suitable for running any cl.exe, b2 has to pick one anyway and run the corresponding environment setup scripts. It is totally our decision which one we pick.
+100 I wasn't going to make that point myself, but this is exactly my point. There is no such thing as a default build for MSVC. You call whichever MSVC binary outputs ARM, PPC, Itanium, x86 ot x64. So what therefore most resembles GCC and clang on other platforms? Whatever is the architecture the OS is running on, so if Linux is running on ARM, you would expect GCC to output ARM binaries suitable for the host OS. Same should go on Windows. If I call b2.exe on Windows x64, I should get x64 MSVC just as if should I call b2.exe on Windows ARM, I should get ARM MSVC not x86 MSVC.
So my vote is for building 64-bit binaries on a 64-bit system by default. This is also consistent with other systems.
I absolutely agree. I would mention it prominantly in the release notes though or with a warning from b2 on Windows as the error message you get when trying to link incompatible binaries on Windows isn't too obvious about the cause. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/