Thank you for the quick replies. I was inspired by https://gcc.gnu.org/ml/gcc-help/2012-04/msg00223.html but it seems, according to your comments, that was outdated. The problem on my Mac was each of the processes used no more than 10% of a core. Now I know that it's not so inefficient on other platforms, but I might try rewriting it in the future if I have time, as I believe there's still some room for optimizations. Thanks
Sent: Monday, January 14, 2019 at 4:57 PM From: "Richard Biener" <richard.guent...@gmail.com> To: "Rainer Orth" <r...@cebitec.uni-bielefeld.de> Cc: "MCC CS" <mc...@gmx.com>, "GCC Development" <gcc@gcc.gnu.org> Subject: Re: Replacing DejaGNU On Mon, Jan 14, 2019 at 2:54 PM 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. > > There's no such problem on other targets, not even e.g. on Mac OS X 10.7. If I would take a guess then it's security checks (verifying signatures for each process invocation?). IIRC you can disable this system-wide somehow (of course that's not recommended). Richard. > Rainer > > -- > ----------------------------------------------------------------------------- > Rainer Orth, Center for Biotechnology, Bielefeld University