http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43706
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43706
Richard Guenther changed:
What|Removed |Added
Target Milestone|4.5.2 |4.5.3
--- Comment #28 from Richard Gue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43706
--- Comment #27 from Jakub Jelinek 2010-12-02
14:31:31 UTC ---
Author: jakub
Date: Thu Dec 2 14:31:27 2010
New Revision: 167371
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167371
Log:
PR libgomp/43706
* env.c (initialize_env):
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43706
--- Comment #26 from Johannes Singler 2010-11-15
08:53:12 UTC ---
(In reply to comment #25)
> 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 te
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43706
--- Comment #25 from Alexander Peslyak
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43706
--- Comment #24 from Johannes Singler 2010-11-12
08:15:56 UTC ---
If only one out of 35 tests becomes slower, I would rather blame it to this one
(probably badly parallelized) application, not the OpenMP runtime system. So I
would suggest a thre
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43706
--- Comment #23 from Alexander Peslyak
2010-11-09 16:32:53 UTC ---
(In reply to comment #20)
> Maybe we could agree on a compromise for a start. Alexander, what are the
> corresponding results for GOMP_SPINCOUNT=10?
I reproduced slowdown of
--- Comment #22 from solar-gcc at openwall dot com 2010-09-05 11:37 ---
(In reply to comment #20)
> Maybe we could agree on a compromise for a start. Alexander, what are the
> corresponding results for GOMP_SPINCOUNT=10?
Unfortunately, I no longer have access to the dual-X5550 syst
--- Comment #21 from jakub at gcc dot gnu dot org 2010-09-01 16:38 ---
*** Bug 45485 has been marked as a duplicate of this bug. ***
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #20 from singler at kit dot edu 2010-08-30 08:41 ---
Maybe we could agree on a compromise for a start. Alexander, what are the
corresponding results for GOMP_SPINCOUNT=10?
--
singler at kit dot edu changed:
What|Removed |Added
--- Comment #19 from solar-gcc at openwall dot com 2010-08-24 12:18 ---
(In reply to comment #18)
> Then, at the start of the spinning libgomp could initialize that flag and
> check
> it from time to time (say every few hundred or thousand iterations) whether it
> has lost the CPU.
Wit
--- Comment #18 from jakub at gcc dot gnu dot org 2010-08-24 11:40 ---
For the auto-tuning, ideally the kernel would tell the thread when it lost CPU,
I doubt there is any API for that currently. E.g. if a thread could register
with kernel address where the kernel would store some value
--- Comment #17 from solar-gcc at openwall dot com 2010-08-24 11:07 ---
(In reply to comment #16)
> I would really like to see this bug tackled.
I second that.
> Fixing it is easily done by lowering the spin count as proposed. Otherwise,
> please show cases where a low spin count hurt
--- Comment #16 from singler at kit dot edu 2010-08-13 15:48 ---
I would really like to see this bug tackled. It has been confirmed two more
times.
Fixing it is easily done by lowering the spin count as proposed. Otherwise,
please show cases where a low spin count hurts performance.
--- Comment #15 from johnfb at mail dot utexas dot edu 2010-07-30 14:00
---
We have also had some trouble with this issue. We found that in general if we
where running on a machine with hardware threads (i.e., Intel's
Hyper-Threading) then performance was poor. Most of our runs where on
--- Comment #14 from solar-gcc at openwall dot com 2010-07-02 01:39 ---
We're also seeing this problem on OpenMP-using code built with gcc 4.5.0
release on linux-x86_64. Here's a user's report (400x slowdown on an 8-core
system when there's a single other process running on a CPU):
htt
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.4 |4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43706
--- Comment #13 from singler at kit dot edu 2010-04-23 14:17 ---
The default spin count is not 2,000,000 cycles, but even 20,000,000. As
commented in libgomp/env.c, this is supposed to correspond to 200ms. The
timings we see here are even larger, but the number of cycles is just a roug
--- Comment #12 from mika dot fischer at kit dot edu 2010-04-21 14:23
---
Just to make it clear, this patch most probably does not fix the issue we're
having, since it can be triggered without using GOMP_CPU_AFFINITY.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43706
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43706
--- Comment #11 from jakub at gcc dot gnu dot org 2010-04-21 14:05 ---
GOMP_CPU_AFFINITY vs. throttling fixed for 4.4.4/4.5.1/4.6.0.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #10 from jakub at gcc dot gnu dot org 2010-04-21 14:01 ---
Subject: Bug 43706
Author: jakub
Date: Wed Apr 21 14:00:10 2010
New Revision: 158601
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158601
Log:
PR libgomp/43706
* config/linux/affinity.c (gomp
--- Comment #9 from jakub at gcc dot gnu dot org 2010-04-21 14:00 ---
Subject: Bug 43706
Author: jakub
Date: Wed Apr 21 13:59:39 2010
New Revision: 158600
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158600
Log:
PR libgomp/43706
* config/linux/affinity.c (gomp_
--- Comment #8 from jakub at gcc dot gnu dot org 2010-04-20 15:38 ---
Subject: Bug 43706
Author: jakub
Date: Tue Apr 20 15:37:51 2010
New Revision: 158565
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158565
Log:
PR libgomp/43706
* config/linux/affinity.c (gomp_
--- Comment #7 from mika dot fischer at kit dot edu 2010-04-20 12:23
---
> For performance reasons libgomp uses some busy waiting, which of course works
> well when there are available CPUs and cycles to burn (decreases latency a
> lot), but if you have more threads than CPUs it can mak
--- Comment #6 from jakub at gcc dot gnu dot org 2010-04-20 10:49 ---
Created an attachment (id=20441)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20441&action=view)
gcc46-pr43706.patch
For GOMP_CPU_AFFINITY there was an issue that the number of available CPUs used
to decide whe
--- Comment #5 from jakub at gcc dot gnu dot org 2010-04-20 10:23 ---
For performance reasons libgomp uses some busy waiting, which of course works
well when there are available CPUs and cycles to burn (decreases latency a
lot), but if you have more threads than CPUs it can make things w
--- Comment #4 from mika dot fischer at kit dot edu 2010-04-09 22:10
---
I'm Martin's coworker and want to add some additional points.
Just be be clear, this is not an exotic toy example, it is causing us real
problems with production code. Martin just stripped it down so it can be eas
--- Comment #3 from baeuml at kit dot edu 2010-04-09 20:55 ---
> Have you done a profile (using oprofile) to see why this happens.
I've oprofile'd the original program from which this is a stripped down minimal
example. I did not see anything unusual, but I'm certainly no expert with
o
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-04-09 18:33 ---
Have you done a profile (using oprofile) to see why this happens. Really I
think GOMP_CPU_AFFINITY should not be used that much as it will cause
starvation no matter what.
--
http://gcc.gnu.org/bugzilla/show_bug
--- Comment #1 from baeuml at kit dot edu 2010-04-09 16:22 ---
Created an attachment (id=20348)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20348&action=view)
output of -save-temps
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43706
31 matches
Mail list logo
