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
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.
IMHO _now_ is the right time to think about performance, and not after
the check-in, as performance PR's do not have the highest priority, as
past experience shows.
Cheers,
Manfred
> Knuth: "We should forget about small efficiencies, say about 97%
> of the time: premature optimization is the root of all evil. Yetr
> we should not pass up our opportunities in that critical 3%"
>
> Or http://c2.com/cgi/wiki?MakeItWorkMakeItRightMakeItFast
>