Re: [patch,libgfortran] PR48298 DTIO implementation for Internal Units

[Manfred Schwarb <manfred99 at gmx dot ch>]

Am 15.09.2016 um 03:08 schrieb Jerry DeLisle:
> On 09/14/2016 02:42 PM, Steve Kargl wrote:
>> On Wed, Sep 14, 2016 at 11:02:04PM +0200, Manfred Schwarb wrote:
>>> Am 14.09.2016 um 19:33 schrieb Steve Kargl:
>>>> On Wed, Sep 14, 2016 at 08:46:00AM -0700, Jerry DeLisle wrote:
>>>>>
>>>>> Well so much for my hopes. I have done some large loop tests with two strings 
>>>>> inside the loop. One is KIND=1 and one is KIND=4.
>>>>>
>>>>> I see a 15% slowdown.  My guess is its in the treap search and stack overhead.
>>>>>
>>>>
>>>> I suspect you'll find that the slowdown will depend
>>>> on what you are writing into the string.  Try formatting
>>>> a REAL(16), which is a software 128-bit floating implementation.
>>>>
>>>> IMHO, a working, complete, implementation of DTIO is worth
>>>> any slowdown.  Someone worried about speed can try to 
>>>> optimize/change the nascent stack algorithm.
>>>>
>>>
>>> Sorry, Steve, I do not agree.
>>> It's not about premature optimization, it is about potentially
>>> making existing, central code paths slower.
>>> And traditionally, Fortran is about reading data, doing number crunching
>>> with it and writing data out again. Nothing sophisticated.
>>> So for me, and perhaps most gfortran users, DTIO is only nice to have,
>>> so with "worth any slowdown" I can't agree with.
>>
>> Jerry has a patch that fixes a 5.5 year old PR.  It appears
>> to work.  It appears to be correct.  I'm sure he'll accept
>> your help to make it fast.
>>
>> Jerry has shown a 15% slowdown in a synthetic piece of code.
>> It would be prudent to see how the code functions with actual
>> code.  Committing the code is the only way to get real testing,
>> because asking people to apply the patch to trunk, rebuild
>> gfortran, and test their codes will ensure the patch will never
>> get committed.
>>
> 
> Both Manfred and Steve have good points to consider. In actual application is
> 15% on only 5% of the code execution?
> 
> Hard to say if its significant at this point.
> 
> Can anyone suggest a code base to check with?  Maybe CP2K?
> 

I quickly assembled a short demo of something which can occur in reality:
Reading a text file with unknown length, and try to parse the input as real numbers
if possible.

#!/bin/sh
{
for ((i=1; i<=100000; ++i)); do
  echo "1 2 3 4 5"
  echo "11 12 13 14 15 NA"
  echo "21 22 23 24 25 NA 27"
  echo "31 32 33 34 35 NA 37 38"
  echo "41 42 43 44 45 NA 47 48 49"
done
} > tmp.txt
exit

      PROGRAM myprogram
      INTEGER i
      REAL val
      CHARACTER*500 buffer
      CHARACTER*20 tmparr(100)

      OPEN(10,FILE="tmp.txt")
   10 CONTINUE
      tmparr=" "
      !---We do not know how many elements are on the line:
      READ(10,'(a)',END=100) buffer
      READ(buffer,*,END=101,ERR=102) tmparr
      GOTO 101
  102 CONTINUE
      PRINT*,"Do something to treat errors"
  101 CONTINUE
      DO i=1,100
        IF (LEN_TRIM(tmparr(i)).GT.0) THEN
          !---We try to parse the input as numbers:
          READ(tmparr(i),'(f20.0)',ERR=103) val
          !!PRINT*,"We found a number, do something meaningful with it"
          CYCLE
  103     CONTINUE
          !!PRINT*,"Input is not parsable, do something else"
        ELSE
          EXIT
        ENDIF
      ENDDO
      GOTO 10
  100 CONTINUE
      CLOSE(10)
      END

On my box this runs in 6.5 seconds

HTH,
Manfred


> Comments appreciated,
> 
> Jerry
>