Re: [Patch, fortran] PR35339 Optimize implied do loops in io statements

[Nicolas Koenig <koenigni at student dot ethz dot ch>]

Hello Jerry,

it already handles READ statements ;)

Those were the results i got:

gcc@dcm-linux:~/pr/35339> cat perf_test.f90
program main
    implicit none
    integer:: i
    integer, parameter:: N = 10000000
    integer, dimension(N):: g

    do i=1,N
        g(i) = i
    end do

open(10,file="test.dat")
    write (10,*) (g(i), i=1,N)
close(10)
end program

gcc@dcm-linux:~/pr/35339> gfortran -O3 perf_test.f90
gcc@dcm-linux:~/pr/35339> time ./a.out

real    0m1.879s
user    0m1.838s
sys     0m0.040s
gcc@dcm-linux:~/pr/35339> gfortran-7 -O3 perf_test.f90
gcc@dcm-linux:~/pr/35339> time ./a.out

real    0m1.929s
user    0m1.901s
sys     0m0.028s

It does seem to make everything a bit faster, but not by much. At least
it gets rid of most of the loops that make problems with asynchronous
io. I noticed while writing the patch that "a(1:size(a):1)" isn't converted
to "a(FULL)". Would their be any performance gain in doing this?

Nicolas

On 05/29/2017 12:06 AM, Jerry DeLisle wrote:
> On 05/27/2017 12:49 PM, Nicolas Koenig wrote:
> > Hello everyone,
> >
> > attached is a patch to simplify implied do loops in io statements by 
> > replacing them with their respective array slices. For example "WRITE 
> > (*,*) (a(i), i=1,4,2)" becomes "WRITE (*,*) a(1:4:2)".
> >
> > Ok for trunk?
>
> Thanks for patch. Could you do some timing performance tests with and 
> without the patch on large arrays and see if we gain anything?
>
> Also, we should expand the test case to include implied do loops in 
> read statements. You could probably just rewind the file, copy down 
> the WRITEs and change them to READs or similar and check results.
>
> While doing some checks myself I noticed some odd behavior and found 
> PR53029. I posted a patch, but what caught my attention was the 
> implied do version was faster than the array version. (about .89 sec 
> vs 6 sec)
>
> So with my patch there I am now getting (.89 sec vs .007 sec)
>
> This prompted me to have you check some performance cases.
>
> Thanks for additional feedback,
>
> Jerry