Polyhedron test: gas_dyn run-time performance regression compared with yesterday

Polyhedron test: gas_dyn run-time performance regression compared with yesterday

[Tobias Burnus]

This is using the Polyhedron Fortran test.
http://www.polyhedron.co.uk/MFL6VW74649

Using several options, the gas_dyn test got much slower; however, with
some options, the performance remained roughly the same.
In terms of the geometric mean, it is a slowdown of around 1%.
The run time of the other programs only changed slightly (up/down/const).


Result from http://www.suse.de/~gcctest/c++bench/polyhedron/
-ffast-math -funroll-loops -O3 -ftree-vectorize -march= ??? (opteron I
think).
14.59s -> 21.06s (44% slower)


Result on for my AMD Athlon64 4800+,
http://physik.fu-berlin.de/~tburnus/gcc-trunk/benchmark/
Yesterday: 2007-09-10-r128322
Today: 2007-09-11-r128363

gfortran -march=opteron -ffast-math -funroll-loops -ftree-loop-linear
-ftree-vectorize -msse3 -O3
11.55s -> 15.95s (40% slower) [geo.mean: 24.34 -> 24.67]

gfortran -march=opteron -ffast-math -funroll-loops -ftree-vectorize
-ftree-loop-linear -msse3 -fvect-cost-model
Unchanged: 11.57s -> 11.54s [geo.mean: 24.27->24.29]

gfortran -fprofile-use -march=opteron -ffast-math -funroll-loops
-ftree-loop-linear -ftree-vectorize -O3
Unchanged: 11.56s -> 11.17s [geo.mean: 23.78s -> 23.90s]

gfortran -m32 -march=opteron -ffast-math -funroll-loops
-ftree-loop-linear -ftree-vectorize -O3
13.50s -> 24.11s (78% slower) [geo.mean: 27.30->27.48]

gfortran -m32 -march=opteron -ffast-math -funroll-loops
-ftree-loop-linear -ftree-vectorize -mfpmath=sse -msse3 -O3
13.29 -> 18.98 (43% slower) [geo.mean: 25.76s->26.25s]

Tobias

RE: Polyhedron test: gas_dyn run-time performance regression compared with yesterday

[Jagasia, Harsha]

Hello!
>
>> This is using the Polyhedron Fortran test.
>> http://www.polyhedron.co.uk/MFL6VW74649
>
>> Using several options, the gas_dyn test got much slower; however,
with
>> some options, the performance remained roughly the same.
>> In terms of the geometric mean, it is a slowdown of around 1%.
>> The run time of the other programs only changed slightly
(up/down/const).
>
>
>> Result from http://www.suse.de/~gcctest/c++bench/polyhedron/
>> -ffast-math -funroll-loops -O3 -ftree-vectorize -march= ??? (opteron
I
>> think).
>> 14.59s -> 21.06s (44% slower)
>
>
>> Result on for my AMD Athlon64 4800+,
>> http://physik.fu-berlin.de/~tburnus/gcc-trunk/benchmark/
>> Yesterday: 2007-09-10-r128322
>> Today: 2007-09-11-r128363
>
>The problem was introduced by r128353 [1]:

Sorry, this is fixed by Ira's patch at
http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00966.html

The new times are:

NV      V-no-cm    V-cm
15.85   11.02       11.14

There is a small regression introduced by the cost model now. This
should get fixed as we tune the costs some more in stage 3.

Thanks,
Harsha

RE: Polyhedron test: gas_dyn run-time performance regression compared with yesterday

[Jagasia, Harsha]

>> Result from http://www.suse.de/~gcctest/c++bench/polyhedron/
>> -ffast-math -funroll-loops -O3 -ftree-vectorize -march= ??? (opteron
I
>> think).
>> 14.59s -> 21.06s (44% slower)
>

I will look into it right now, but at first glance it does not look like
this benchmark is built with the cost model enabled.


Thanks,

>
>> Result on for my AMD Athlon64 4800+,
>> http://physik.fu-berlin.de/~tburnus/gcc-trunk/benchmark/
>> Yesterday: 2007-09-10-r128322
>> Today: 2007-09-11-r128363
>
>The problem was introduced by r128353 [1]:
>
>2007-09-10  Harsha Jagasia <harsha.jagasia@amd.com>
>            Jan Sjodin <jan.sjodin@amd.com>
>
>        * tree-vect-analyze.c (vect_analyze_operations): Change
>        comparison of loop iterations with threshold to less than
>        or equal to instead of less than. Reduce
>        min_scalar_loop_bound by one.
>        * tree-vect-transform.c (vect_estimate_min_profitable_iters):
>        Change prologue and epilogue iterations estimate to vf/2,
>        when unknown at compile-time. Change versioning guard
>        cost to taken_branch_cost. If peeling for alignment is
>        unknown at compile-time, change peel guard costs to one
>        taken branch and one not-taken branch per peeled loop.
>        If peeling for alignment is known but number of scalar loop
>        iterations is unknown at compile-time, change peel guard
>        costs to one taken branch per peeled loop. Change the cost
>        model equation to consider vector iterations as the loop
>        iterations less the prologue and epilogue iterations.
>        Change outside vector cost check to less than or equal to
>        zero instead of equal to zero.
>        (vect_do_peeling_for_loop_bound): Reduce
>        min_scalar_loop_bound by one.
>        * tree-vectorizer.h: Add TARG_COND_TAKEN_BRANCH_COST and
>        TARG_COND_NOT_TAKEN_BRANCH_COST.
>        ...
>
>[1]: http://gcc.gnu.org/ml/gcc-cvs/2007-09/msg00347.html
>
>Uros.
>

Re: Polyhedron test: gas_dyn run-time performance regression compared with yesterday

[Uros Bizjak]

Hello!

> This is using the Polyhedron Fortran test.
> http://www.polyhedron.co.uk/MFL6VW74649

> Using several options, the gas_dyn test got much slower; however, with
> some options, the performance remained roughly the same.
> In terms of the geometric mean, it is a slowdown of around 1%.
> The run time of the other programs only changed slightly (up/down/const).


> Result from http://www.suse.de/~gcctest/c++bench/polyhedron/
> -ffast-math -funroll-loops -O3 -ftree-vectorize -march= ??? (opteron I
> think).
> 14.59s -> 21.06s (44% slower)


> Result on for my AMD Athlon64 4800+,
> http://physik.fu-berlin.de/~tburnus/gcc-trunk/benchmark/
> Yesterday: 2007-09-10-r128322
> Today: 2007-09-11-r128363

The problem was introduced by r128353 [1]:

2007-09-10  Harsha Jagasia <harsha.jagasia@amd.com>
            Jan Sjodin <jan.sjodin@amd.com>

        * tree-vect-analyze.c (vect_analyze_operations): Change
        comparison of loop iterations with threshold to less than
        or equal to instead of less than. Reduce
        min_scalar_loop_bound by one.
        * tree-vect-transform.c (vect_estimate_min_profitable_iters):
        Change prologue and epilogue iterations estimate to vf/2,
        when unknown at compile-time. Change versioning guard
        cost to taken_branch_cost. If peeling for alignment is
        unknown at compile-time, change peel guard costs to one
        taken branch and one not-taken branch per peeled loop.
        If peeling for alignment is known but number of scalar loop
        iterations is unknown at compile-time, change peel guard
        costs to one taken branch per peeled loop. Change the cost
        model equation to consider vector iterations as the loop
        iterations less the prologue and epilogue iterations.
        Change outside vector cost check to less than or equal to
        zero instead of equal to zero.
        (vect_do_peeling_for_loop_bound): Reduce
        min_scalar_loop_bound by one.
        * tree-vectorizer.h: Add TARG_COND_TAKEN_BRANCH_COST and
        TARG_COND_NOT_TAKEN_BRANCH_COST.
        ...

[1]: http://gcc.gnu.org/ml/gcc-cvs/2007-09/msg00347.html

Uros.