[Bug libfortran/38199] [4.7/4.8/4.9 Regression] missed optimization: I/O performance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199 Jerry DeLisle changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #45 from Jerry DeLisle --- Fixed and closing.
[Bug libfortran/38199] [4.7/4.8/4.9 Regression] missed optimization: I/O performance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199 --- Comment #44 from Jerry DeLisle --- Author: jvdelisle Date: Sat Mar 15 23:06:44 2014 New Revision: 208599 URL: http://gcc.gnu.org/viewcvs?rev=208599&root=gcc&view=rev Log: 2014-03-15 Jerry DeLisle Backport from mainline PR libfortran/58324 PR libfortran/38199 * intrinsics/string_intriniscs_inc.c (string_len_trim): Remove prototypes for string_len_trim and move to... * libgfortran.h (string_len_trim): ... here and (string_len_trim_char4): ...here. * io/list_read.c (finish_list_read): Read one character to check for the end of the file. If it is the end, then issue the file end error message. If not, use eat_line to reach the end without giving error. The next attempt to read will then issue the error as described above. * io/read.c (read_decimal): Quickly skip spaces to avoid calls to next_char. * io/unit.c (is_trim_ok): New helper function to check various conditions to see if its OK to trim the internal unit string. (get_internal_unit): Use LEN_TRIM to shorten selected internal unit strings for optimizing READ. Enable this optimization for formatted READ. Backport from mainline PR libfortran/58324 * gfortran.dg/list_read_12.f90: New test. Added: branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/list_read_12.f90 Modified: branches/gcc-4_7-branch/gcc/testsuite/ChangeLog branches/gcc-4_7-branch/libgfortran/ChangeLog branches/gcc-4_7-branch/libgfortran/intrinsics/string_intrinsics_inc.c branches/gcc-4_7-branch/libgfortran/io/list_read.c branches/gcc-4_7-branch/libgfortran/io/read.c branches/gcc-4_7-branch/libgfortran/io/unit.c branches/gcc-4_7-branch/libgfortran/libgfortran.h
[Bug libfortran/38199] [4.7/4.8/4.9 Regression] missed optimization: I/O performance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199 --- Comment #43 from Jerry DeLisle --- Author: jvdelisle Date: Sat Mar 15 20:31:33 2014 New Revision: 208595 URL: http://gcc.gnu.org/viewcvs?rev=208595&root=gcc&view=rev Log: 2014-03-15 Jerry DeLisle Backport from mainline PR libfortran/58324 PR libfortran/38199 * io/list_read.c (finish_list_read): Read one character to check for the end of the file. If it is the end, then issue the file end error message. If not, use eat_line to reach the end without giving error. The next attempt to read will then issue the error as described above. * io/read.c (read_decimal): Quickly skip spaces to avoid calls to next_char. * io/unit.c (is_trim_ok): New helper function to check various conditions to see if its OK to trim the internal unit string. (get_internal_unit): Use LEN_TRIM to shorten selected internal unit strings for optimizing READ. Enable this optimization for formatted READ. Modified: branches/gcc-4_8-branch/libgfortran/ChangeLog branches/gcc-4_8-branch/libgfortran/io/list_read.c branches/gcc-4_8-branch/libgfortran/io/read.c branches/gcc-4_8-branch/libgfortran/io/unit.c
[Bug libfortran/38199] [4.7/4.8/4.9 Regression] missed optimization: I/O performance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199 --- Comment #42 from Jerry DeLisle --- Author: jvdelisle Date: Thu Mar 13 05:06:57 2014 New Revision: 208528 URL: http://gcc.gnu.org/viewcvs?rev=208528&root=gcc&view=rev Log: 2014-03-12 Jerry DeLisle PR libfortran/38199 * io/read.c (read_decimal): Quickly skip spaces to avoid calls to next_char. * io/unit.c (is_trim_ok): New helper function to check various conditions to see if its OK to trim the internal unit string. (get_internal_unit): Use LEN_TRIM to shorten selected internal unit strings for optimizing READ. Enable this optimization for formatted READ. * io/list_read.c (finish_list_read): Don't call eat_line for internal units. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/list_read.c trunk/libgfortran/io/read.c trunk/libgfortran/io/unit.c
[Bug libfortran/38199] [4.7/4.8/4.9 Regression] missed optimization: I/O performance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199 --- Comment #40 from Jerry DeLisle --- Created attachment 32335 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32335&action=edit Updated patch taking care of NIST failures and cleaned up This patch regression tests and passes NIST on x86-64. I have restructured it and took care of leaping on uninitialized values. Dominiq. Can you give it a spin? Thanks
[Bug libfortran/38199] [4.7/4.8/4.9 Regression] missed optimization: I/O performance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199 --- Comment #39 from Jerry DeLisle --- OK, I can reproduce this here. The problem is the read is trying to go past where we adjusted the string length due to things like 1X and / in the format. Good catch, thanks
[Bug libfortran/38199] [4.7/4.8/4.9 Regression] missed optimization: I/O performance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199 --- Comment #38 from Dominique d'Humieres --- > Dominiq, can you try FM908 with something like Valgrind and also try > different > optimization levels and see if anything odd pops up. I don't have access to valgrind on this machine, but if I compile with -fsanitize=address, I get ... 7 FAIL COMPUTED= 0.34D-03 CORRECT= 0.3438457000D+03 8 FAIL COMPUTED= 0.00D+00 CORRECT= 0.3438457000D+03 9 FAIL COMPUTED= 0.00D+00 CORRECT= 0.3438457000D+03 ... 27 FAIL COMPUTED= (34.84000, 0.0) CORRECT= (34.84000,349.88699) ... 43 PASS 1 TEST PASS/FAIL DISPLAYED RESULTS REMARKS --- At line 727 of file /Users/dominiq/Documents/Fortran/NISTtest/NIST/FM908.f Fortran runtime error: Bad value on logical read
[Bug libfortran/38199] [4.7/4.8/4.9 Regression] missed optimization: I/O performance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199 --- Comment #37 from Jerry DeLisle --- Here on NIST I do not get any failures. FM908 passes FM905 and FM907 require inspection to confirm and they look good. I only need to adjust the reference output file that is used by the script to do the inspection for me. Dominiq, can you try FM908 with something like Valgrind and also try different optimization levels and see if anything odd pops up.
[Bug libfortran/38199] [4.7/4.8/4.9 Regression] missed optimization: I/O performance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199 --- Comment #36 from Dominique d'Humieres --- When running the NIST tests from a script, I see the following failure with the patch: FM908 fails to run At line 727 of file /Users/dominiq/Documents/Fortran/NISTtest/NIST/FM908.f Fortran runtime error: Bad value on logical read However the test succeeds when run manually.
[Bug libfortran/38199] [4.7/4.8/4.9 Regression] missed optimization: I/O performance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199 --- Comment #35 from Dominique d'Humieres --- > http://gcc.gnu.org/ml/fortran/2014-03/msg00079.html The test character buffer*10 integer i,j DO j=1, write(buffer,'(i4)') j read(buffer,'(i10)') i ENDDO end takes ~3.5s without the patch (and 4.7.4 or 4.8.3) and ~0.7s with it (~2s with 4.6). The test character buffer(1)*10 integer i,j DO j=1, write(buffer(1),'(i4)') j read(buffer,*) i ENDDO end takes ~1.8s with/without the patch (~11.3s with 4.6, ~10.2s with 4.7.4, and ~13.6 with 4.8.3, i7 2.8Ghz, turbo 3.8Ghz).
[Bug libfortran/38199] [4.7/4.8/4.9 Regression] missed optimization: I/O performance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199 --- Comment #34 from Jerry DeLisle --- http://gcc.gnu.org/ml/fortran/2014-03/msg00079.html
[Bug libfortran/38199] [4.7/4.8/4.9 Regression] missed optimization: I/O performance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199 --- Comment #33 from Jerry DeLisle --- Author: jvdelisle Date: Sun Mar 9 05:34:34 2014 New Revision: 208439 URL: http://gcc.gnu.org/viewcvs?rev=208439&root=gcc&view=rev Log: 2014-03-08 Jerry DeLisle PR libfortran/38199 * io/list_read.c (next_char): Mark unlikely error checks. (eat_spaces): For character array reading, skip ahead over spaces rather than call next_char multiple times. Modified: trunk/libgfortran/ChangeLog
[Bug libfortran/38199] [4.7/4.8/4.9 Regression] missed optimization: I/O performance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199 --- Comment #32 from Jerry DeLisle --- Created attachment 32312 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32312&action=edit New patch for case in comment 21 This is just a preliminary runtime patch. Without: real0m7.519s user0m7.496s sys0m0.000s With patch: real0m1.433s user0m1.424s sys0m0.002s Which is not a bad improvement. I am still looking at what we could do on the front-end.
[Bug libfortran/38199] [4.7/4.8/4.9 Regression] missed optimization: I/O performance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199 --- Comment #31 from Jerry DeLisle --- Author: jvdelisle Date: Sun Mar 9 03:17:16 2014 New Revision: 208438 URL: http://gcc.gnu.org/viewcvs?rev=208438&root=gcc&view=rev Log: 2014-03-08 Jerry DeLisle PR libfortran/38199 * io/list_read.c (next_char): Delete unuseful error checks. (eat_spaces): For character array reading, skip ahead over spaces rather than call next_char multiple times. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/list_read.c
[Bug libfortran/38199] [4.7/4.8/4.9 Regression] missed optimization: I/O performance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199 --- Comment #30 from Jerry DeLisle --- The read: read(buffer,'(i10)') i is an entirely different code path then the example in Comment #22 because of the format specifier. This is handled very differently from a list directed read. In read_block_form we take the users intent of i10 very literally. I also see how we can do a trim on it. I will work on this as a separate patch, keeping in mind this test case is well contrived. :)
[Bug libfortran/38199] [4.7/4.8/4.9 Regression] missed optimization: I/O performance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199 --- Comment #29 from Manfred Schwarb --- The regression flag was re-added by Tobias in comment 23 due to a regression in the testcase of comment 21: !234567 character buffer*10 integer i,j DO j=1, write(buffer,'(i4)') j write(*,*) buffer(1:4) read(buffer,'(i10)') i write(*,*) i ENDDO end Here are the profiles of gfortran 4.6: Each sample counts as 0.01 seconds. % cumulative self self total time seconds secondscalls Ts/call Ts/call name 97.45 3.06 3.06 _gfortrani_read_decimal 1.59 3.11 0.05 memset 0.64 3.13 0.02 __write_nocancel 0.32 3.14 0.01 format_lex 0.00 3.14 0.001 0.00 0.00 main and gfortran trunk: Each sample counts as 0.01 seconds. % cumulative self self total time seconds secondscalls Ts/call Ts/call name 59.96 2.71 2.71 read_utf8 38.72 4.46 1.75 _gfortrani_read_decimal 0.66 4.49 0.03 memset 0.22 4.50 0.01 fflush 0.22 4.51 0.01 formatted_transfer 0.22 4.52 0.01 malloc_consolidate 0.00 4.52 0.001 0.00 0.00 main so the difference is obvious, the utf8 treatment makes the difference. Is there a possibility to speed up reading the trivial cases? 99.99% of fortran input will be ASCII, I guess... And again, the magical approach is to add LEN_TRIM to avoid reading 10 space characters and interpreting them as utf8. So if something like Thomas' patch could be applied also for formatted reads, this would speed up things dramatically as well.
[Bug libfortran/38199] [4.7/4.8/4.9 Regression] missed optimization: I/O performance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199 --- Comment #28 from Jerry DeLisle --- Patch submitted for the case in Comment #22. $ gfc48 22.f gfortran version 4.8 $ time ./a.out real0m26.320s user0m26.184s sys0m0.018s $ gfc 22.f gfortran patched trunk $ time ./a.out real0m2.917s user0m2.902s sys0m0.001s
[Bug libfortran/38199] [4.7/4.8/4.9 Regression] missed optimization: I/O performance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199 --- Comment #27 from Jerry DeLisle --- Getting my self up to speed here. I reviewed what we have going on with this. Currently we call a function called eat_spaces to do what is needed. Naturally, to keep track of all the flags and counters, eat_spaces just calls next_char. next_char handles all the details, but is not optimized to just skip over spaces. If we wanted to break our paradigm, we could go straight to memory and just scan the string and skip the spaces. Another option is to use the sread call which goes straight to mem_read in unix.c Another option would be to not even store the spaces and use a NULL marker and then pad spaces on writes when we see it and stop reads. This would be most efficient, but is a very intrusive and could lead to problems when accessing the middle of strings, etc, etc, etc. I will be attempting to use sread in a better way for eat_spaces and see how it turns out.
[Bug libfortran/38199] [4.7/4.8/4.9 Regression] missed optimization: I/O performance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199 --- Comment #26 from Jerry DeLisle --- Test case from Comment #22 ifort: real0m0.608s user0m0.464s sys0m0.080s gfortran: real0m22.893s user0m21.059s sys0m0.152s Obviously we could do better.
[Bug libfortran/38199] [4.7/4.8/4.9 Regression] missed optimization: I/O performance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199 Richard Biener changed: What|Removed |Added Target Milestone|4.7.3 |4.7.4 --- Comment #25 from Richard Biener 2013-04-11 07:58:45 UTC --- GCC 4.7.3 is being released, adjusting target milestone.
