This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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?

Comments appreciated,

Jerry


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]