From: Paolo Bonzini <bonzini@gnu.org>
To: Arnaud Charlet <charlet@adacore.com>
Cc: Duncan Sands <baldrick@free.fr>, gcc-patches@gcc.gnu.org
Subject: Re: [Ada] Speed up build of gnatools
Date: Tue, 06 Sep 2011 15:17:00 -0000 [thread overview]
Message-ID: <4E663985.60704@gnu.org> (raw)
In-Reply-To: <20110906115650.GA65634@adacore.com>
On 09/06/2011 01:56 PM, Arnaud Charlet wrote:
>> this means using as many processes as there are CPUs, right? It seems pretty
>
> Right, but only for gnattools, which is a relatively short time, and
> which always occurs at the end of the build (so with nothing else
> running at the same time).
>
>> dubious to me to use more processes than the user maybe asked for. For example
>> I have to restrict the number of CPUs used when building GCC to less than I have
>> since otherwise my machine overheats and turns itself off. Is there some way
>> to get at the -j level the user passed to the top-level make and use that?
>
> No, I'm not aware of a way to get this information.
The solution would be to support running gnatmake as a client of make's
job server. In short:
1) gnatmake should look for the MAKEFLAGS environment variable, and look
for the --jobserver-fds= option found inside it. The option receives a
comma-separated list of two file descriptors. The first is an "input"
pipe, the second is an "output" pipe.
2) before invoking any child process, gnatmake should ensure the child
doesn't see the two pipes (unless the child were also an instance of
make/gnatmake).
3) *after* invoking any child process, gnatmake should perform a
blocking 1-byte read from the "input" pipe.
4) after reaping any child process, gnatmake should perform a blocking
1-byte write to the "output" pipe.
5) you should add a + in front of rules that use gnatmake.
Paolo
WARNING: multiple messages have this Message-ID
From: Paolo Bonzini <bonzini@gnu.org>
To: gcc-patches@gcc.gnu.org
Cc: Duncan Sands <baldrick@free.fr>, gcc-patches@gcc.gnu.org
Subject: Re: [Ada] Speed up build of gnatools
Date: Tue, 06 Sep 2011 15:25:00 -0000 [thread overview]
Message-ID: <4E663985.60704@gnu.org> (raw)
Message-ID: <20110906152500.aY4SPyutrQ0KxarywILX-FnO6RmbJ1-W4AjPVMeLmuM@z> (raw)
In-Reply-To: <20110906115650.GA65634@adacore.com>
On 09/06/2011 01:56 PM, Arnaud Charlet wrote:
>> this means using as many processes as there are CPUs, right? It seems pretty
>
> Right, but only for gnattools, which is a relatively short time, and
> which always occurs at the end of the build (so with nothing else
> running at the same time).
>
>> dubious to me to use more processes than the user maybe asked for. For example
>> I have to restrict the number of CPUs used when building GCC to less than I have
>> since otherwise my machine overheats and turns itself off. Is there some way
>> to get at the -j level the user passed to the top-level make and use that?
>
> No, I'm not aware of a way to get this information.
The solution would be to support running gnatmake as a client of make's
job server. In short:
1) gnatmake should look for the MAKEFLAGS environment variable, and look
for the --jobserver-fds= option found inside it. The option receives a
comma-separated list of two file descriptors. The first is an "input"
pipe, the second is an "output" pipe.
2) before invoking any child process, gnatmake should ensure the child
doesn't see the two pipes (unless the child were also an instance of
make/gnatmake).
3) *after* invoking any child process, gnatmake should perform a
blocking 1-byte read from the "input" pipe.
4) after reaping any child process, gnatmake should perform a blocking
1-byte write to the "output" pipe.
5) you should add a + in front of rules that use gnatmake.
Paolo
next prev parent reply other threads:[~2011-09-06 15:17 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-06 10:57 Arnaud Charlet
2011-09-06 11:14 ` Duncan Sands
2011-09-06 11:57 ` Arnaud Charlet
2011-09-06 15:17 ` Paolo Bonzini [this message]
2011-09-06 15:25 ` Paolo Bonzini
2011-09-06 13:27 ` Robert Dewar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E663985.60704@gnu.org \
--to=bonzini@gnu.org \
--cc=baldrick@free.fr \
--cc=charlet@adacore.com \
--cc=gcc-patches@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).