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

[Jerry DeLisle <jvdelisle at charter dot net>]

On 09/14/2016 10:33 AM, Steve Kargl wrote:
> 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.
> 
> 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
> 

I agree. Of curiosity I ran some profiles. There is no one offending culprit. I
see malloc is at the top of the list at 8% and free is right under about the
same.  Looking at unpatched trunk it is about the same percentage wise, just
lower overall time. I am thinking we commit this with a new PR to track the
issue, perhaps as a performance regression so we don't lose it in the pile.

Will wait for others comments and pending approval.

Jerry

PS My spell checker translates DTIO into IDIOT, cracks me up every time I see it