http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199
--- Comment #16 from Manfred Schwarb <manfred99 at gmx dot ch> 2012-03-19
09:42:29 UTC ---
Thanks, Janne, for your patch. It does not help very much, though.
[ As expected, as the reading part is the bottleneck ]
My current timings of the second test case:
g77: 12.41s
4.3: 14.60s
4.5: 18.55s
4.7: 17.21s
4.8: 16.80s (inkl. Janne's patch)
len_trim variant, 4.3: 0.92s
len_trim variant, 4.8: 0.24s
That's still a factor 70 (sic!) away from the optimized variant.
And we are still slower than GCC 4.3 and g77.
The len_trim variant improved a lot, probably due
to Janne's patch.
Now, the interesting thing is:
I tried to figure out at which point the len_trim variant
is slower due to the len_trim overhead.
On my box, this point does not exist, i.e. the len_trim
variant is always faster!
I.e. even for
character buffer*10
the len_trim variant is faster!
Which suggests that a brute-force approach to unconditionally
issue a "len_trim" in the relevant gfortran reading routine
would always be a win!
