Re: [boost] [1.58.0] Release candidates available

Subject: Re: [boost] [1.58.0] Release candidates available
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2015-04-08 09:29:36

> -----Original Message-----
> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Vladimir Prus
> Sent: 08 April 2015 12:46
> To: boost_at_[hidden]
> Subject: Re: [boost] [1.58.0] Release candidates available

> > The OS can not throttle a running process' greediness for RAM, at
> > least I don't think so. It could prevent new processes to start, but
> > that is also tricky for the OS in a general sense. This is however
> > trivial for a build system when deciding whether it should start
> > additional parallel compiler invocations that are totally optional tuning for build speed. It
make no sense
> to start additional compilations in parallel if you see the physical RAM is consumed.  The tricky
part is
> knowing when to stop adding parallel tasks to prevent getting in a consumed RAM state in the first
place.
> And hopefully still leave ample space for the rest of the system to live.
> 
> On my system right now, there's 142M of free memory (and similar amount of buffers). That does
sound
> sufficient for any compilation these days, still -j4 build is OK, since OS discards most of that
memory and
> swaps the other quite easily. I am not sure we can answer "is there enough RAM" question reliably.
> 
> Likewise, "will 4 jobs too much I/O" question is not easy to answer.

Would the uber-naïve heuristic -jone_less_than_max_cores work OK-ish (for a desktop machine)?

For those following develop (and rebuilding libraries more often) a user-config setting sounds good.

There are enough other options to specify.

(And convenient and flexible for others too).

Paul

---
Paul A. Bristow
Prizet Farmhouse
Kendal UK LA8 8AB
[phone]