These are chat archives for Fortran-FOSS-Programmers/General-Discussion

May 2017
Stefano Zaghi
May 04 2017 03:29
@cmacmackin Chris, this is just a feeling, I have not yet done accurate comparisons (just run some small tests, indeed large being 1D tests), the non-pure allocatable polymorphic version was not really usable in production due to the memory leaks. Today, I can try a more rigorous analysis (with gcc 7.1), but in the 1D tests I did, the performance improvement seems visible. However, this fact could be not (only) related to the purity: now my math operators really works on plain real arrays, each operator (+, -, *, /, **) returns a real array, polymorphic classes are totally out from this kind of operators (polymorphism returns in play, without allocatable, in assignment) , thus I think that the intrinsic optimal handling of arrays of Fortran can play a role (or I had a wrong feeling and the performance boost is not there :cry: ).
Chris MacMackin
May 04 2017 12:19
@szaghi I just wonder because I was under the impression that PURE was mostly used for handling things like parallelisation. I'd have thought that most of the opportunities for parallelisation would occur within the type-bound operators and not in making parallel calls to the operators themselves. The big advantage I can see to your new approach, though, is that it would make it much easier to use abstract calculus with coarrays, since function results are not allowed to contain coarray components. In Scientific Software Design it was proposed that you would essentially have two versions of your types: one with coarray components and one without, where the non-coarray version would be used for function results. This greatly increases the ammount of code needed, whereas just using arrays would be much simpler. The disadvantage is that it becomes harder to use new defined operators, such as .div., .grad., .curl., on function results because they wouldn't have the necessary information about grid-layout.
Chris MacMackin
May 04 2017 12:26

On a different note, you say you're using gcc 7.1. I compiled that today using the OpenCoarrays script. I wanted to see if it got rid of the memory leaks in my project. However, when I tried running my test suite, I found that it produced the error

Fortran runtime error: Recursive call to nonrecursive procedure 'cheb1d_scalar_grid_spacing'

When I examined the backtrace and the code, it seemed that a call to totally different type-bound procedure got mixed up with the one called grid_spacing. This happened twice, which is what ended up producing the "recursion". I have no idea what could be wrong with the compiler to produce this. Is it working properly for you?

Stefano Zaghi
May 04 2017 12:29
@cmacmackin I run a simple test with 7.1. If you can wait few minutes I can try a more serious test (memory leaks seem to be still here with 7.1...)
Chris MacMackin
May 04 2017 12:32
Good to know.
Stefano Zaghi
May 04 2017 12:34

@cmacmackin Chris, I have just run a more complex test with this

╼ stefano@zaghi(02:32 PM Thu May 04) on feature/add-riemann-2D-tests [!?] desk {gcc-7.1.0 - gcc 7.1.0 environment}
├───╼ ~/fortran/FORESEER 15 files, 840Kb
└──────╼ gfortran --version
GNU Fortran (GCC) 7.1.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO

It seems to work exactly as in gcc 6.3

the test is in FORESEER, this one and uses a lot of OOP
Chris MacMackin
May 04 2017 12:42
Okay, something must have gone wrong with how I compiled it. If it doesn't solve the memory leaks then I won't bother pursuing it any further.
Stefano Zaghi
May 04 2017 12:43
Let me check the memory leaks issues with the dedicated tests, few minutes again :smile:
@cmacmackin Chris, we are not very fortunate... the leaks seems to be still there
╼ stefano@zaghi(02:43 PM Thu May 04) on master desk {gcc-7.1.0 - gcc 7.1.0 environment}
├───╼ ~/fortran/leaks_hunter 3 files, 88Kb
└──────╼ scripts/ src/leaks_raiser_static_intrinsic.f90 

┌╼ stefano@zaghi(02:43 PM Thu May 04) on master [?] desk {gcc-7.1.0 - gcc 7.1.0 environment}
├───╼ ~/fortran/leaks_hunter 4 files, 100Kb
└──────╼ scripts/ 
==59798== Memcheck, a memory error detector
==59798== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==59798== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info
==59798== HEAP SUMMARY:
==59798==     in use at exit: 4 bytes in 1 blocks
==59798==   total heap usage: 20 allocs, 19 frees, 12,012 bytes allocated
==59798== Searching for pointers to 1 not-freed blocks
==59798== Checked 101,856 bytes
==59798== 4 bytes in 1 blocks are definitely lost in loss record 1 of 1
==59798==    at 0x4C2AF1F: malloc (in /usr/lib/valgrind/
==59798==    by 0x40075C: __static_intrinsic_type_m_MOD_add_static_intrinsic_type (leaks_raiser_static_intrinsic.f90:24)
==59798==    by 0x40084D: MAIN__ (leaks_raiser_static_intrinsic.f90:37)
==59798==    by 0x40089F: main (leaks_raiser_static_intrinsic.f90:30)
==59798== LEAK SUMMARY:
==59798==    definitely lost: 4 bytes in 1 blocks
==59798==    indirectly lost: 0 bytes in 0 blocks
==59798==      possibly lost: 0 bytes in 0 blocks
==59798==    still reachable: 0 bytes in 0 blocks
==59798==         suppressed: 0 bytes in 0 blocks
==59798== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
==59798== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Chris MacMackin
May 04 2017 12:49
Was it only 4 bytes lost before? I'd almost worry that was just some issue with initialisation or something.
Stefano Zaghi
May 04 2017 13:34
@cmacmackin Chris, this is a synthetic test designed to raise GNU memory leaks, you can check it on leaks_hunter
The test is very simple, it must return 0 bytes lost
In few hours I should be able to compare performances of polymorphic operators and real ones