Boost logo

Boost :

Subject: Re: [boost] [boost, config, context, log, 1.58] address-model and architecture detection
From: Rob Stewart (rob.stewart_at_[hidden])
Date: 2015-04-07 04:45:58


On April 7, 2015 2:38:59 AM EDT, Andrey Semashev <andrey.semashev_at_[hidden]> wrote:
> On Tue, Apr 7, 2015 at 8:58 AM, Gavin Lambert <gavinl_at_[hidden]>
> wrote:
> >
> > Building 64-bit on Windows is not the preferred option for the vast
> majority
> > of applications, for compatibility reasons.
> >
> > 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.

Right

> 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).
>
> BTW, I think 32-bit Windows spread is overestimated. Here are some
> stats from Steam, for example (click "OS Version" in the table):
>
> http://store.steampowered.com/hwsurvey/
>
> 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.
>
> So my vote is for building 64-bit binaries on a 64-bit system by
> default. This is also consistent with other systems.

We always build Boost 64b.

___
Rob

(Sent from my portable computation engine)


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk