[Bug libgomp/50098] New: The OpenMP ordered construct blocks parallelism, when appearing at the beginning of a loop body

["terechko at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>]

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

             Bug #: 50098
           Summary: The OpenMP ordered construct blocks parallelism, when
                    appearing at the beginning of a loop body
    Classification: Unclassified
           Product: gcc
           Version: 4.4.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libgomp
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: terechko@gmail.com


Created attachment 25021
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25021
program illustrating the performance issue of the ordered construct

According to the OpenMP spec, the ordered construct enforces sequential
ordering of the ordered region. In the GNU OpenMP implementation it works fine,
if the ordered construct resides at the end of the loop body. However, when it
is in the beginning, the parallelism is blocked.

Using the attached C program, the timing figures for the sequential, ordered in
the beginning and ordered in the end versions of the code are presented on a
4-core Intel CPU. The timing shows that the version, where the ordered
construct sits in the beginning of the loop body, has a slowdown, whereas the
version with the ordered construct at the end of the loop body is faster than
the sequential code.

andrei@jos:~/src$ gcc ordered_perf_bug.c -o /tmp/a.out
andrei@jos:~/src$ time /tmp/a.out

real    0m5.411s
user    0m5.400s
sys    0m0.000s
andrei@jos:~/src$ gcc -fopenmp ordered_perf_bug.c -o /tmp/a.out
andrei@jos:~/src$ time /tmp/a.out

real    0m6.155s
user    0m24.530s
sys    0m0.010s
andrei@jos:~/src$ gcc -DFAST_ORDERED -fopenmp ordered_perf_bug.c -o /tmp/a.out
andrei@jos:~/src$ time /tmp/a.out

real    0m3.082s
user    0m12.290s
sys    0m0.000s

andrei@jos:~/src$ gcc --version
gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

andrei@jos:~/src$ uname -a
Linux jos 2.6.32-27-generic #49-Ubuntu SMP Thu Dec 2 00:51:09 UTC 2010 x86_64
GNU/Linux
andrei@jos:~/src$ lshw 
jos                       
    description: Computer
    width: 64 bits
    capabilities: vsyscall64 vsyscall32
  *-core
       description: Motherboard
       physical id: 0
     *-memory
          description: System memory
          physical id: 0
          size: 3922MiB
     *-cpu
          product: Intel(R) Core(TM) i5 CPU         760  @ 2.80GHz
          vendor: Intel Corp.
          physical id: 1
          bus info: cpu@0
          size: 1197MHz
          capacity: 1197MHz
          width: 64 bits
          capabilities: fpu fpu_exception wp vme de pse tsc msr pae mce cx8
apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht
tm pbe syscall nx rdtscp x86-64 constant_tsc arch_perfmon pebs bts rep_good
xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2
ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida tpr_shadow vnmi
flexpriority ept vpid cpufreq
...

P.S. Looking at the GOMP_ordered_end(void) implementation, I suspect that it
needs some synchronization code to fix the reported performance issue.