Boost logo

Boost :

Subject: Re: [boost] [1.58.0] Release candidates available
From: Bjørn Roald (bjorn_at_[hidden])
Date: 2015-04-07 15:42:16


On 07. april 2015 12:05, Vladimir Prus wrote:
> On 04/07/2015 11:40 AM, Rob Stewart wrote:
>> On April 7, 2015 4:22:05 AM EDT, Olaf van der Spek <ml_at_[hidden]> wrote:
>>> On Tue, Apr 7, 2015 at 10:00 AM, Andrey Semashev
>>> <andrey.semashev_at_[hidden]> wrote:
>>>>> Could b2 default to -jX where X is the number of cores?
>>>>
>>>> This would be unexpected
>>>
>>> Why?
>>
>> It would be unlike other build tools, like make. It would be an
>> breaking interface change.
>>
>>>> and detrimental if there is not enough RAM.
>>>
>>> How much RAM is needed?
>>
>> It scales almost linearly, I imagine. Each compiler instance requires
>> memory to build a translation unit.
>>
>> If Boost used to build fine on a limited machine, it might slow to a
>> crawl due to paging with the added parallelism. Such users would have
>> to use -j1 to avoid that problem.
>>
>> Those with memory enough and more CPUs need to opt in to benefit, of
>> course, but the build doesn't swamp such machines by default. However,
>> if the option could be set in user.jam, then those that wish to opt in
>> can do so once and then forget about it.
>
> Rob, it used to be possible to do:
>
> import option ;
> option.set jobs : 4 ;
>
> in user-config.jam, but that appears to have regressed. Is that what
> you're after?
>

This would be a nice config setting.

Also, in principle, bjam could check available free RAM before invoking
a new parallel task. I think -j 4 does not mean it _has_ to run 4 tasks
in parallel, rather it means up to 4 tasks in paralell. An implicit -j
<hardware_concurrency> certainly should throttle on system resources, so
why not available RAM as well as available cores.

http://stackoverflow.com/questions/150355/programmatically-find-the-number-of-cores-on-a-machine

http://stackoverflow.com/questions/2513505/how-to-get-available-memory-c-g

--
Bjørn

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