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 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