This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
RE: [PATCH] gcc parallel make check
- From: "VandeVondele Joost" <joost dot vandevondele at mat dot ethz dot ch>
- To: Richard Biener <richard dot guenther at gmail dot com>, Jakub Jelinek <jakub at redhat dot com>
- Cc: Mike Stump <mikestump at comcast dot net>, David Malcolm <dmalcolm at redhat dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, "fortran at gcc dot gnu dot org" <fortran at gcc dot gnu dot org>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, "libstdc++ at gcc dot gnu dot org" <libstdc++ at gcc dot gnu dot org>
- Date: Tue, 16 Sep 2014 16:04:42 +0000
- Subject: RE: [PATCH] gcc parallel make check
- Authentication-results: sourceware.org; auth=none
- References: <20140911075123 dot GN17454 at tucnak dot redhat dot com> <20140911080640 dot GP17454 at tucnak dot redhat dot com> <20140911145300 dot GR17454 at tucnak dot redhat dot com> <908103EDB4893A42920B21D3568BFD93150F876D at MBX23 dot d dot ethz dot ch> <908103EDB4893A42920B21D3568BFD93150FE8D2 at MBX13 dot d dot ethz dot ch> <20140912163241 dot GC17454 at tucnak dot redhat dot com> <305370A6-ACBC-4DD4-AF96-32B3503F3388 at comcast dot net> <20140915160549 dot GM17454 at tucnak dot redhat dot com> <64B425D3-EDE8-4F28-B815-F9D374730F7F at comcast dot net> <CAFiYyc2TpoHsCtXospY96S4=17kbBce-c8EcV1S5=b-hcbp-Vg at mail dot gmail dot com> <20140916092830 dot GV17454 at tucnak dot redhat dot com>,<CAFiYyc0xYFV6zRd4NNxf4eWQDPyaD5VgKJ8kL_W70dmth8fVVg at mail dot gmail dot com>
>> > These numbers are useful to try and ensure the overhead (scaling factor) is reasonable, thanks.
>>
>> A nice improvement indeed. The patched result is 15 times faster
>> than the serial unpatched run. So there is room for improvement
>
> Note, the box used was oldish AMD 16-core, no ht, box, haven't tried it on anything
on a 32 core box, no ht, I see these timings:
time make -j32 -k check >& log.check32 ; time make -j8 -k check >& log.check8
real 18m14.562s
user 260m21.578s
sys 264m26.042s
real 41m33.210s
user 233m4.563s
sys 72m11.429s
so it is not quite reaching the ideal 4x speedup. Counting the number of 'expect' processes they are nicely at around 32 and 8 for the full test, with only a very short tail near the end. So, there might be some overhead somewhere. Total user time is similar, but time in sys goes up.