This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: [patch,libgfortran] PR48298 DTIO implementation for Internal Units
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.
--
Steve