[Bug libgomp/61333] New: potential target specific performance issue with libgomp

[Bug libgomp/61333] New: potential target specific performance issue with libgomp

[howarth.at.gcc at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61333

            Bug ID: 61333
           Summary: potential target specific performance issue with
                    libgomp
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libgomp
          Assignee: unassigned at gcc dot gnu.org
          Reporter: howarth.at.gcc at gmail dot com
                CC: jakub at gcc dot gnu.org

While benchmarking the new openmp/clang-omp support against gcc/libgomp on
x86_64-apple-darwin13, I noticed a potential performance issue in gcc/libgomp
on darwin. Using the attached heated_plate_openmp.c and heated_plate_gcc.sh
shell script, I am seeing reproducible timing on darwin that ratio to the
timing for one thread as..

gcc 4.8.3   1:1.90:3.31
gcc 4.9.0   1:1.90:3.30
clang 2.4   1:1.99:3.71

compared to Fedora 15 linux 

gcc 4.6.3   1:1.99:3.92

This is where the timings for the one, two and four OMP processes are
normalized to the timing for one OMP process.

Unfortunately I don't have access to gcc 4.8.3 or 4.9.0 to test on linux.
The timings are reproducible and suggest that darwin may have a performance
issue for higher number of OMP threads.

[Bug libgomp/61333] potential target specific performance issue with libgomp

[howarth.at.gcc at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61333

--- Comment #1 from Jack Howarth <howarth.at.gcc at gmail dot com> ---
Created attachment 32866
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32866&action=edit
heated_plate_openmp.c test code

[Bug libgomp/61333] potential target specific performance issue with libgomp

[howarth.at.gcc at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61333

--- Comment #2 from Jack Howarth <howarth.at.gcc at gmail dot com> ---
Created attachment 32867
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32867&action=edit
heated_plate_gcc.sh shell script to collect timings

[Bug libgomp/61333] potential target specific performance issue with libgomp

[howarth.at.gcc at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61333

--- Comment #3 from Jack Howarth <howarth.at.gcc at gmail dot com> ---
FYI, the timings on clang are for clang 3.4.1 with a merge of current clang-omp
github commit f9e2fd7640f8fc06ebe1ef2f065c6158f6b4b6ef and openmp svn trunk
from llvm.org at r208472/

[Bug libgomp/61333] potential target specific performance issue with libgomp

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61333

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The reason why GCC on linux is better is because it uses the futex syscall to
have better locking (lower overhead).  See config/linux/{mutex,lock}.c.

While on Darwin, it directly calls into pthread_mutex calls.

[Bug libgomp/61333] potential target specific performance issue with libgomp

[howarth.at.gcc at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61333

--- Comment #5 from Jack Howarth <howarth.at.gcc at gmail dot com> ---
It would be interesting to find out what Intel openmp is doing differently on
darwin since it is significantly faster on four threads.

[Bug libgomp/61333] potential target specific performance issue with libgomp

[howarth.at.gcc at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61333

--- Comment #6 from Jack Howarth <howarth.at.gcc at gmail dot com> ---
There is a call to pthread_cond_timedwait() in the libiomp5 implementation but
I don't see any such calls in libgomp. Perhaps this is the related to the
increased performance in libiomp5 on darwin?

[Bug libgomp/61333] potential target specific performance issue with libgomp

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61333

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Jack Howarth from comment #6)
> There is a call to pthread_cond_timedwait() in the libiomp5 implementation
> but I don't see any such calls in libgomp. Perhaps this is the related to
> the increased performance in libiomp5 on darwin?

I also see direct use of spin locks rather than calling into the pthread
library.  Maybe the pthread library has an syscall overhead.

[Bug libgomp/61333] potential target specific performance issue with libgomp

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61333

--- Comment #8 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Some comments:

original shell: 1:1.86:2.9
+ -Ofast      : 1:1.37:1.8

(gcc 4.10.0 r210749). Does this mean that there is a problem with -Ofast and
-fopenmp?

The Wallclock time are:

original shell: 46.49s:25.83s:16.02s
+ -Ofast      : 7.82s:5.72s:4.21s

Estimating an Amdahl's law: s+p/n (s serial time, p parallel time, n number of
threads), based on n=1 and 2, gives

original shell: s= 5.17s, p=41.32s, time for n=4: 15.50s,
+ -Ofast      : s=3.63s, p=4.19s, time for n=4: 4.68s.

This crude estimate shows that the serial time is only slightly improved with
-Ofast while the parallel one is an order of magnitude faster with it.

Could you give the Wallclock time for the different cases in comment 0?

[Bug libgomp/61333] potential target specific performance issue with libgomp

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61333

--- Comment #9 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> ... (gcc 4.10.0 r210749) ...

Forgot to say: Target: x86_64-apple-darwin13, Corei7, 4 cores, 8 threads,
2.8Ghz
(turbo 3.8Ghz), cache 8Mb. Note that the "turbo" mode may make the serial test
faster.

[Bug libgomp/61333] potential target specific performance issue with libgomp

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61333

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Note, libgomp is optimized for Linux futexes, it has bare support for other
targets, so unless somebody steps up and submits and maintains a port for other
OSes, those will keep using pthread_* APIs with no particular performance work.

So, if you want to do any benchmarking, do it on Linux, not on darwin.

Also, benchmarking -O0 code is weird.

The benchmark looks prehistoric too, even OpenMP 3.1 has min/max reductions.

[Bug libgomp/61333] potential target specific performance issue with libgomp

[howarth.at.gcc at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61333

--- Comment #11 from Jack Howarth <howarth.at.gcc at gmail dot com> ---
(In reply to Jakub Jelinek from comment #10)

> Also, benchmarking -O0 code is weird.

Is gcc really optimizing that low by default? Certainly it is at least doing
-O1 when not passed a -O* optimization flag? In any case, shouldn't the
optimization be somewhat orthogonal to this problem since, by normalizing to
the one process timing, we are just looking at the effect of the overhead in
the processes?

[Bug libgomp/61333] potential target specific performance issue with libgomp

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61333

--- Comment #12 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> Is gcc really optimizing that low by default? ...

AFAIK the default optimization in gcc is -O0. Now before drawing conclusions
you should answer my question in comment 8.

[Bug libgomp/61333] potential target specific performance issue with libgomp

[howarth.at.gcc at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61333

--- Comment #13 from Jack Howarth <howarth.at.gcc at gmail dot com> ---
(In reply to Dominique d'Humieres from comment #12)
> > Is gcc really optimizing that low by default? ...
> 
> AFAIK the default optimization in gcc is -O0. Now before drawing conclusions
> you should answer my question in comment 8.

Without optimization flags on a 16-core MacPro under darwin13, the timings for
one, two and four OMP processes are…

clang-3.4.1 (clang-omp/openmp) 82.913658 sec: 41.704652 sec: 22.256563 sec
gcc 4.8.3                      96.409755 sec: 50.521193 sec: 28.822280 sec
gcc 4.9.0                      96.341129 sec: 50.563898 sec: 28.850048 sec

at -O1
clang-3.4.1 (clang-omp/openmp) 19.371284 sec:  9.743520 sec:  5.938325 sec
gcc 4.8.3                      38.253825 sec: 21.149855 sec: 13.426259 sec 
gcc 4.9.0                      38.170274 sec: 21.022076 sec: 13.402209 sec

at -O2
clang-3.4.1 (clang-omp/openmp) 15.621070 sec:  7.890557 sec:  5.384909 sec
gcc 4.8.3                      18.473835 sec: 11.278842 sec:  8.954324 sec
gcc 4.9.0                      18.468089 sec: 11.208950 sec:  8.949956 sec

at -O3
clang-3.4.1 (clang-omp/openmp) 15.627173 sec:  8.073639 sec:  5.870642 sec
gcc 4.8.3                      18.535541 sec: 11.258917 sec:  8.951850 sec
gcc 4.9.0                      17.088016 sec: 10.685973 sec:  8.884664 sec

at -Os
clang-3.4.1 (clang-omp/openmp) 19.365366 sec:  9.732779 sec:  5.360228 sec
gcc 4.8.3                      19.523171 sec: 11.657896 sec:  8.993581 sec
gcc 4.9.0                      18.472308 sec: 11.224615 sec:  8.959600 sec

at -Ofast
clang-3.4.1 (clang-omp/openmp) 12.533942 sec:  6.371977 sec:  5.358282 sec
gcc 4.8.3                      15.593206 sec:  9.804462 sec:  8.581757 sec
gcc 4.9.0                      14.145020 sec:  9.089317 sec:  8.449206 sec
>From gcc-bugs-return-452731-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed May 28 15:37:41 2014
Return-Path: <gcc-bugs-return-452731-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 18965 invoked by alias); 28 May 2014 15:37:41 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 18920 invoked by uid 48); 28 May 2014 15:37:37 -0000
From: "vmakarov at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/61325] [4.10 regression] aarch64_be build fails
Date: Wed, 28 May 2014 15:37:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: rtl-optimization
X-Bugzilla-Version: 4.10.0
X-Bugzilla-Keywords: build
X-Bugzilla-Severity: normal
X-Bugzilla-Who: vmakarov at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.10.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-61325-4-Id1FFtJsvC@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61325-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61325-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-05/txt/msg02423.txt.bz2
Content-length: 759

https://gcc.gnu.org/bugzilla/show_bug.cgi?ida325

Vladimir Makarov <vmakarov at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vmakarov at gcc dot gnu.org

--- Comment #2 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
The patch for PR60969 just triggered a bug.  Process_address in
lea-constraints.c just did one transformation ind * scale + base + dips =>
base2 = base + dips, ind * scale + base2.  The new address is still illegal as
we changed memory mode from DI to QI and scale is still 4.  So we need to do
more one transformation.

I hope to make a patch and commit it tomorrow.

[Bug libgomp/61333] potential target specific performance issue with libgomp

[howarth.at.gcc at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61333

--- Comment #14 from Jack Howarth <howarth.at.gcc at gmail dot com> ---
Without optimization flags on a 24-core x86_64 Fedora 15 box, the timings for
one, two and four OMP processes are…

clang-3.4.0 (clang-omp/openmp)  69.988439 sec:  34.962212 sec:  17.641935 sec
gcc 4.6.3                       81.324524 sec:  40.878640 sec:  20.741782 sec
gcc 4.8 branch svn              80.953598 sec:  40.650732 sec:  20.635248 sec

at -O1
clang-3.4.0 (clang-omp/openmp)  16.187348 sec:   8.189783 sec:   4.293277 sec
gcc 4.6.3                       32.315830 sec:  16.233432 sec:   8.257077 sec
gcc 4.8 branch svn              32.292952 sec:  16.270113 sec:   8.258137 sec

at -O2
clang-3.4.0 (clang-omp/openmp)  13.463402 sec:   6.690053 sec:   3.570961 sec
gcc 4.6.3                       15.671699 sec:   7.895216 sec:   4.133647 sec
gcc 4.8 branch svn              15.639710 sec:   7.878182 sec:   4.120302 sec

at -O3
clang-3.4.0 (clang-omp/openmp)  13.260507 sec:   6.698891 sec:   3.559403 sec
gcc 4.6.3                       15.947264 sec:   7.991567 sec:   4.158251 sec
gcc 4.8 branch svn              15.607232 sec:   7.861177 sec:   4.150581 sec

at -Os
clang-3.4.0 (clang-omp/openmp)  16.266355 sec:   8.229083 sec:   4.236148 sec
gcc 4.6.3                       16.921628 sec:   8.539645 sec:   4.447783 sec
gcc 4.8 branch svn              15.914723 sec:   8.658947 sec:   4.719782 sec

at -Ofast
clang-3.4.0 (clang-omp/openmp)  10.822510 sec:   5.500982 sec:   3.484604 sec
gcc 4.6.3                       13.752500 sec:   6.764537 sec:   3.601730 sec
gcc 4.8 branch svn              13.224638 sec:   6.658421 sec:   3.556949 sec
>From gcc-bugs-return-452747-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed May 28 17:58:00 2014
Return-Path: <gcc-bugs-return-452747-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 23638 invoked by alias); 28 May 2014 17:57:59 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 23586 invoked by uid 48); 28 May 2014 17:57:54 -0000
From: "mrs at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug other/61146] wide-int error when building GCC with clang
Date: Wed, 28 May 2014 17:57:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: other
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: mrs at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-61146-4-laDZdXfGga@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61146-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61146-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-05/txt/msg02439.txt.bz2
Content-length: 146

https://gcc.gnu.org/bugzilla/show_bug.cgi?ida146

--- Comment #11 from mrs at gcc dot gnu.org <mrs at gcc dot gnu.org> ---
Yes, weird, thanks.