-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Vladimir Prus Sent: 08 April 2015 12:46 To: boost@lists.boost.org 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 +44 (0) 1539 561830