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

[Jerry DeLisle <jvdelisle at charter dot net>]

On 09/15/2016 01:15 AM, Manfred Schwarb wrote:
> 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.

---snip---

On my laptop:

trunk patched 17.747

trunk unpatched 15.199

There are some low hanging fruit things I will try, but this is not too bad for 
approximately 1,000,000 + operations ( 5 lines * 100,000 * 2 READs + some).

Stay tuned.

Jerry