Hi Iain,
>> On 14 Jan 2019, at 13:53, Rainer Orth <r...@cebitec.uni-bielefeld.de> wrote:
>>
>> "MCC CS" <mc...@gmx.com> writes:
>>
>>> I've been running the testsuite on my macOS, on which
>>> it is especially unbearable. I want to (at least try to)
>>
>> that problem may well be macOS specific: since at least macOS 10.13
>> (maybe even 10.12; cannot currently tell for certain) make -jN check
>> times on my Mac mini skyrocketed with between 60 and 80% system time.
>> It seems this is due to lock contention on one specific kernel lock, but
>> I haven't been able to find out more yet.
>
> this PR mentions the compilation, but it’ even more apparent on test.
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84257
>
> * Assuming SIP is disabled.
>
> Some testing suggests that each DYLD_LIBRARY_PATH entry adds around 2ms to
> each exe launch.
> So .. when you’re doing something that’s a lot of work per launch, not much
> is seen - but when you’re doing things with a huge number of exe launches -
> e.g. configuring or running the test suite, it bites.
>
> A work-around is to remove the RPATH_ENVAR variable setting in the top
> level Makefile.in (which actually has the same effect as running things
> with SIP enabled)
this change alone helped tremendously: a bootstrap on macOS 10.14 on
20181103 took
180041.05 real 96489.89 user 180864.44 sys
while the current one was only
44886.30 real 74101.86 user 36879.75 sys
However, not unexpectedly quite a number of new failures occur,
e.g. many (all?) plugin tests FAIL with
cc1: error: cannot load plugin ./selfassign.so
dlopen(./selfassign.so, 10): Symbol not found: __ZdlPvm
Referenced from: ./selfassign.so
Expected in: /usr/lib/libstdc++.6.dylib
in ./selfassign.so
compiler exited with status 1
I'll still have to check which are affected this way.
> === DejaGNU on macOS...
>
> DejaGNU / expect are not fantastic on macOS, even given the comments above
> - it’s true. Writing an interpreter/funnel for the testsuite has crossed
> my mind more than once.
>
> However, I suspect it’s a large job, and it might be more worth investing
> any available effort in debugging the slowness in expect/dejaGNU -
> especially the lock contention that Rainer mentions.
Indeed: I found it when trying to investigate the high system time with
lockstat. However, I don't know a way how to relate the lock address
mentioned there to some lock in the darwin sources.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
