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.
