Re: [boost] [boost, config, context, log, 1.58] address-model and architecture detection

Subject: Re: [boost] [boost, config, context, log, 1.58] address-model and architecture detection
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-04-07 18:26:34

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/