This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [libgomp, testsuite] Support parallel testing in libgomp (PR libgomp/66005)
- From: Mike Stump <mikestump at comcast dot net>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Rainer Orth <ro at CeBiTec dot Uni-Bielefeld dot DE>, Thomas Schwinge <thomas at codesourcery dot com>, gcc-patches at gcc dot gnu dot org
- Date: Thu, 7 May 2015 11:06:14 -0700
- Subject: Re: [libgomp, testsuite] Support parallel testing in libgomp (PR libgomp/66005)
- Authentication-results: sourceware.org; auth=none
- References: <yddlhh0hblq dot fsf at lokon dot CeBiTec dot Uni-Bielefeld dot DE> <20150507113940 dot GI1751 at tucnak dot redhat dot com>
On May 7, 2015, at 4:39 AM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Thu, May 07, 2015 at 01:26:57PM +0200, Rainer Orth wrote:
>> As reported in the PR, with the addition of all those OpenACC tests,
>> libgomp make check times have skyrocketed since the testsuite is still
>> run sequentially.
>>
>> Even on a reasonably fast x86 machine (4 x 2.0 Ghz Xeon E7450) the run
>> takes 4286 seconds.
>>
>> On slower sparc boxes (1.2 GHz UltraSPARC-T2) we're at 29406 seconds,
>> compared to 7825 seconds on the 4.9 branch.
>>
>> Thus, the libgomp tests massively slow down the whole testsuite run,
>> being the last part to finish.
>>
>> Fixing this proved trivial: I managed to almost literally copy the
>> solution from libstdc++-v3/testsuite/Makefile.am, with a minimal change
>> to libgomp.exp so the generated libgomp-test-support.exp file is found
>> in both the sequential and parallel cases. This isn't an issue in
>> libstdc++ since all necessary variables are stored in a single
>> site.exp.
>
> It is far from trivial though.
> The point is that most of the OpenMP tests are parallelized with the
> default OMP_NUM_THREADS, so running the tests in parallel oversubscribes the
> machine a lot
If OpenMP cannot keep the machine busy, then the test suite should. A 15x speed up means that OpenMP cannot keep the machine busy. I’d not expect OpenMP to fill the gap here, so that leave just the test suite. So, unless someone wants to try their hand at getting some serious time from OpenMP, I think the patch lies on the path of goodness.