[Bug libgomp/43706] scheduling two threads on one core leads to starvation

["solar-gcc at openwall dot com" <gcc-bugzilla@gcc.gnu.org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43706

--- Comment #25 from Alexander Peslyak <solar-gcc at openwall dot com> 2010-11-12 11:19:13 UTC ---
(In reply to comment #24)
> If only one out of 35 tests becomes slower,

You might have misread what I wrote.  I did not mention "35 tests"; I mentioned
that a test became slower by 35%.  The total number of different tests was 4
(and each was invoked multiple times per spincount setting, indeed).  One out
of four stayed 35% slower until I increased GOMP_SPINCOUNT to 200000.

> I would rather blame it to this one (probably badly parallelized) application, not the OpenMP runtime system.

This makes some sense, but the job of an optimizing compiler and runtime
libraries is to deliver the best performance they can even with somewhat
non-optimal source code.  There are plenty of real-world cases where spending
time on application redesign for speed is unreasonable or can only be completed
at a later time - yet it is desirable to squeeze a little bit of extra
performance out of the existing code.  There are also cases where more
efficient parallelization - implemented at a higher level to avoid frequent
switches between parallel and sequential execution - makes the application
harder to use.  To me, one of the very reasons to use OpenMP was to
avoid/postpone that redesign and the user-visible complication for now.  If I
went for a more efficient higher-level solution, I would not need OpenMP in the
first place.

> So I would suggest a threshold of 100000 for now.

My suggestion is 250000.

> IMHO, something should really happen to this problem before the 4.6 release.

Agreed.  It'd be best to have a code fix, though.