Hi Jakub,
> On Wed, May 29, 2019 at 04:13:41PM +0200, Rainer Orth wrote:
>> Prompted by extremely long libgomp make check times due to missing
>> parallelism, I noticed that the current support to restrict testcase
>> parallelism only works on targets which have getconf _NPROCESSORS_ONLN.
>> Instead of adding special cases for all sorts of tools to determine the
>> number of cores, I found a macro in the autoconf-archive that
>> encapsulates just that.
>>
>> The following patch makes use of that, bootstrapped without regressions
>> on i386-pc-solaris2.11 and sparc-sun-solaris2.11 and checked that
>> CPU_COUNT is determined correctly and the OMP_NUMP_THREADS warning
>> emitted. Also rebuilt libgomp on x86_64-pc-linux-gnu and performed the
>> same check.
>>
>> Ok for mainline?
>
> I'd prefer not to determine the CPU count at configure time, the build
> directory can be on some network filesystem and tested sometimes on one
> machine, sometimes on another one, hw can be upgraded etc.
somewhat agreed for testing on one or the other system. However, build
dirs tend to be short-lived in my experience (and usually local because
at least I have found builds on NFS so incredibly slow as to avoid them
like the plague) and hw upgrades are relatively rare.
> So, something similar to what your patch does, but don't substitute the actual
> CPU count, but a command to determine the number of CPUs?
I'm not convinced that would work reliably: you can easily have one set
of commands on one machine, but a slightly different one on another. If
we really want to go this route, that means extracting the autoconf
macro's logic into a separate script and use that at make check time.
Not sure if that's worth the effort, especially since we're not really
interested in the exact number of cores, just small (<= 8) vs. large (> 8).
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
