public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* [Ada] Speed up build of gnatools
@ 2011-09-06 10:57 Arnaud Charlet
  2011-09-06 11:14 ` Duncan Sands
  0 siblings, 1 reply; 6+ messages in thread
From: Arnaud Charlet @ 2011-09-06 10:57 UTC (permalink / raw)
  To: gcc-patches

Now that gnatmake supports -j0, it's possible to speed up the build of
gnattools during GNAT build by using gnatmake -j0 instead of gnatmake.

This is useful since gnattools is the only target which isn't parallelized
in the Makefile before this change.

Tested on x86_64-linux-gnu, committed on trunk.

2011-09-06  Arnaud Charlet  <charlet@adacore.com>
        
	* gcc-interface/Makefile.in (common-tools, gnatmake-re,                 
	gnatlink-re): Speed up by using -j0.

--
Index: gcc-interface/Makefile.in
===================================================================
--- gcc-interface/Makefile.in	(revision 178566)
+++ gcc-interface/Makefile.in	(working copy)
@@ -2336,7 +2336,7 @@
 endif
 
 common-tools:
-	$(GNATMAKE) -c -b $(ADA_INCLUDES) \
+	$(GNATMAKE) -j0 -c -b $(ADA_INCLUDES) \
 	  --GNATBIND="$(GNATBIND)" --GCC="$(CC) $(ALL_ADAFLAGS)" \
 	  gnatchop gnatcmd gnatkr gnatls gnatprep gnatxref gnatfind gnatname \
 	  gnatclean -bargs $(ADA_INCLUDES) $(GNATBIND_FLAGS)
@@ -2375,16 +2375,18 @@
 	$(GNATLINK) -v vxaddr2line -o $@ --GCC="$(GCC_LINK)" targext.o $(CLIB)
 
 gnatmake-re:  link.o targext.o
-	$(GNATMAKE) $(ADA_INCLUDES) -u sdefault --GCC="$(CC) $(MOST_ADA_FLAGS)"
-	$(GNATMAKE) -c $(ADA_INCLUDES) gnatmake --GCC="$(CC) $(ALL_ADAFLAGS)"
+	$(GNATMAKE) -j0 $(ADA_INCLUDES) -u sdefault --GCC="$(CC) $(MOST_ADA_FLAGS)"
+	$(GNATMAKE) -j0 -c $(ADA_INCLUDES) gnatmake --GCC="$(CC) $(ALL_ADAFLAGS)"
 	$(GNATBIND) $(ADA_INCLUDES) $(GNATBIND_FLAGS) gnatmake
 	$(GNATLINK) -v gnatmake -o ../../gnatmake$(exeext) \
 		--GCC="$(GCC_LINK)" $(TOOLS_LIBS)
 
 # Note the use of the "mv" command in order to allow gnatlink to be linked with
 # with the former version of gnatlink itself which cannot override itself.
-gnatlink-re:  link.o targext.o
-	$(GNATMAKE) -c $(ADA_INCLUDES) gnatlink --GCC="$(CC) $(ALL_ADAFLAGS)"
+# gnatlink-re cannot be run at the same time as gnatmake-re, hence the
+# dependency
+gnatlink-re: link.o targext.o gnatmake-re
+	$(GNATMAKE) -j0 -c $(ADA_INCLUDES) gnatlink --GCC="$(CC) $(ALL_ADAFLAGS)"
 	$(GNATBIND) $(ADA_INCLUDES) $(GNATBIND_FLAGS) gnatlink
 	$(GNATLINK) -v gnatlink -o ../../gnatlinknew$(exeext) \
 		    --GCC="$(GCC_LINK)" $(TOOLS_LIBS)

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Ada] Speed up build of gnatools
  2011-09-06 10:57 [Ada] Speed up build of gnatools Arnaud Charlet
@ 2011-09-06 11:14 ` Duncan Sands
  2011-09-06 11:57   ` Arnaud Charlet
  2011-09-06 13:27   ` Robert Dewar
  0 siblings, 2 replies; 6+ messages in thread
From: Duncan Sands @ 2011-09-06 11:14 UTC (permalink / raw)
  To: gcc-patches

Hi Arnaud,

> Now that gnatmake supports -j0, it's possible to speed up the build of
> gnattools during GNAT build by using gnatmake -j0 instead of gnatmake.
>
> This is useful since gnattools is the only target which isn't parallelized
> in the Makefile before this change.

this means using as many processes as there are CPUs, right?  It seems pretty
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?

Ciao, Duncan.

>
> Tested on x86_64-linux-gnu, committed on trunk.
>
> 2011-09-06  Arnaud Charlet<charlet@adacore.com>
>
> 	* gcc-interface/Makefile.in (common-tools, gnatmake-re,
> 	gnatlink-re): Speed up by using -j0.
>
> --
> Index: gcc-interface/Makefile.in
> ===================================================================
> --- gcc-interface/Makefile.in	(revision 178566)
> +++ gcc-interface/Makefile.in	(working copy)
> @@ -2336,7 +2336,7 @@
>   endif
>
>   common-tools:
> -	$(GNATMAKE) -c -b $(ADA_INCLUDES) \
> +	$(GNATMAKE) -j0 -c -b $(ADA_INCLUDES) \
>   	  --GNATBIND="$(GNATBIND)" --GCC="$(CC) $(ALL_ADAFLAGS)" \
>   	  gnatchop gnatcmd gnatkr gnatls gnatprep gnatxref gnatfind gnatname \
>   	  gnatclean -bargs $(ADA_INCLUDES) $(GNATBIND_FLAGS)
> @@ -2375,16 +2375,18 @@
>   	$(GNATLINK) -v vxaddr2line -o $@ --GCC="$(GCC_LINK)" targext.o $(CLIB)
>
>   gnatmake-re:  link.o targext.o
> -	$(GNATMAKE) $(ADA_INCLUDES) -u sdefault --GCC="$(CC) $(MOST_ADA_FLAGS)"
> -	$(GNATMAKE) -c $(ADA_INCLUDES) gnatmake --GCC="$(CC) $(ALL_ADAFLAGS)"
> +	$(GNATMAKE) -j0 $(ADA_INCLUDES) -u sdefault --GCC="$(CC) $(MOST_ADA_FLAGS)"
> +	$(GNATMAKE) -j0 -c $(ADA_INCLUDES) gnatmake --GCC="$(CC) $(ALL_ADAFLAGS)"
>   	$(GNATBIND) $(ADA_INCLUDES) $(GNATBIND_FLAGS) gnatmake
>   	$(GNATLINK) -v gnatmake -o ../../gnatmake$(exeext) \
>   		--GCC="$(GCC_LINK)" $(TOOLS_LIBS)
>
>   # Note the use of the "mv" command in order to allow gnatlink to be linked with
>   # with the former version of gnatlink itself which cannot override itself.
> -gnatlink-re:  link.o targext.o
> -	$(GNATMAKE) -c $(ADA_INCLUDES) gnatlink --GCC="$(CC) $(ALL_ADAFLAGS)"
> +# gnatlink-re cannot be run at the same time as gnatmake-re, hence the
> +# dependency
> +gnatlink-re: link.o targext.o gnatmake-re
> +	$(GNATMAKE) -j0 -c $(ADA_INCLUDES) gnatlink --GCC="$(CC) $(ALL_ADAFLAGS)"
>   	$(GNATBIND) $(ADA_INCLUDES) $(GNATBIND_FLAGS) gnatlink
>   	$(GNATLINK) -v gnatlink -o ../../gnatlinknew$(exeext) \
>   		    --GCC="$(GCC_LINK)" $(TOOLS_LIBS)

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Ada] Speed up build of gnatools
  2011-09-06 11:14 ` Duncan Sands
@ 2011-09-06 11:57   ` Arnaud Charlet
  2011-09-06 15:17     ` Paolo Bonzini
  2011-09-06 13:27   ` Robert Dewar
  1 sibling, 1 reply; 6+ messages in thread
From: Arnaud Charlet @ 2011-09-06 11:57 UTC (permalink / raw)
  To: Duncan Sands; +Cc: gcc-patches

> 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.

I'd suggest playing/experimenting with this change for a while.

If people (e.g. you) report troubles with this change, reverting it is
very easy in any case. I'll be happy to do that.

Arno

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Ada] Speed up build of gnatools
  2011-09-06 11:14 ` Duncan Sands
  2011-09-06 11:57   ` Arnaud Charlet
@ 2011-09-06 13:27   ` Robert Dewar
  1 sibling, 0 replies; 6+ messages in thread
From: Robert Dewar @ 2011-09-06 13:27 UTC (permalink / raw)
  To: Duncan Sands; +Cc: gcc-patches

On 9/6/2011 7:14 AM, Duncan Sands wrote:

> this means using as many processes as there are CPUs, right?  It
> seems pretty dubious to me to use more processes than the user maybe
> asked for.

We often find that the optimum number of processes is a little bit more
than the number of physical processes (not surprising when there is
mixed I/O computation going on.

> 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.

That seems a (pretty disastrous) engineering error in the design of
your machine. In a properly designed machine, extra fans should come
on to counteract the extra heating (that's certainly what happens on
my Toshiba R700 with is the new core i7-2620M with four cores.

> Is there some way to get at the -j level the user passed to the
> top-level make and use that?

I am pretty sure you can specify any -j value you like, but will
let Arno clarify that.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Ada] Speed up build of gnatools
  2011-09-06 11:57   ` Arnaud Charlet
@ 2011-09-06 15:17     ` Paolo Bonzini
  2011-09-06 15:25       ` Paolo Bonzini
  0 siblings, 1 reply; 6+ messages in thread
From: Paolo Bonzini @ 2011-09-06 15:17 UTC (permalink / raw)
  To: Arnaud Charlet; +Cc: Duncan Sands, gcc-patches

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Ada] Speed up build of gnatools
  2011-09-06 15:17     ` Paolo Bonzini
@ 2011-09-06 15:25       ` Paolo Bonzini
  0 siblings, 0 replies; 6+ messages in thread
From: Paolo Bonzini @ 2011-09-06 15:25 UTC (permalink / raw)
  To: gcc-patches; +Cc: Duncan Sands, gcc-patches

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2011-09-06 15:18 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-09-06 10:57 [Ada] Speed up build of gnatools Arnaud Charlet
2011-09-06 11:14 ` Duncan Sands
2011-09-06 11:57   ` Arnaud Charlet
2011-09-06 15:17     ` Paolo Bonzini
2011-09-06 15:25       ` Paolo Bonzini
2011-09-06 13:27   ` Robert Dewar

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).