• gfortran's -fallow-argument-mismatch with old/new compilers

    From Thomas Koenig@21:1/5 to All on Sun Jun 12 11:53:23 2022
    I recently had an e-mail from somebody who ran into trouble
    with old code on gfortran - gfortran 9 did not have the -fallow-argument-mismatch flag, but gfortran 11 required it due
    to issues in the code.

    The solution I proposed was to add something like

    FC_OPTIONS="-O2"
    cat > optiontest.f90 <<EOF
    end
    EOF
    gfortran -fallow-argument-mismatch -fsyntax-only optiontest.f90 \
    /dev/null && FC_OPTIONS="$FC_OPTIONS -fallow-argument-mismatch"
    echo $FC_OPTIONS
    rm optiontest.f90

    to his build scripts, which will add the flag to the FC_OPTIONS
    variable if it is supported, and I thought I'd share it.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Thomas Koenig@21:1/5 to mies...@gmail.com on Fri Jun 17 15:01:32 2022
    mies...@gmail.com <miesiehl@gmail.com> schrieb:
    Thomas Koenig schrieb am Sonntag, 12. Juni 2022 um 13:53:27 UTC+2:
    I recently had an e-mail from somebody who ran into trouble
    with old code on gfortran - gfortran 9 did not have the
    -fallow-argument-mismatch flag, but gfortran 11 required it due
    to issues in the code.

    The solution I proposed was to add something like

    FC_OPTIONS="-O2"
    cat > optiontest.f90 <<EOF
    end
    EOF
    gfortran -fallow-argument-mismatch -fsyntax-only optiontest.f90 \
    /dev/null && FC_OPTIONS="$FC_OPTIONS -fallow-argument-mismatch"
    echo $FC_OPTIONS
    rm optiontest.f90

    to his build scripts, which will add the flag to the FC_OPTIONS
    variable if it is supported, and I thought I'd share it.

    It is certainly an MPICH issue, but I am still using gfortran
    version 9.2.1 just to avoid this -fallow-argument-mismatch flag
    when compiling MPICH for use with gfortran and OpenCoarrays. To me,
    it appears that this flag is somehow related to severe performance
    issues with MPICH and coarray programming.

    I can assure you it is not - the change in question is purely something
    that will downgrade a newly introduced error to a warning.

    Any Performance issues you are seeing may be related to the
    interplay of the OpenCoarrays library with MPICH. Since
    I know neither well, I cannot really comment on that.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From miesiehl@gmail.com@21:1/5 to Thomas Koenig on Fri Jun 17 07:27:12 2022
    Thomas Koenig schrieb am Sonntag, 12. Juni 2022 um 13:53:27 UTC+2:
    I recently had an e-mail from somebody who ran into trouble
    with old code on gfortran - gfortran 9 did not have the -fallow-argument-mismatch flag, but gfortran 11 required it due
    to issues in the code.

    The solution I proposed was to add something like

    FC_OPTIONS="-O2"
    cat > optiontest.f90 <<EOF
    end
    EOF
    gfortran -fallow-argument-mismatch -fsyntax-only optiontest.f90 \ 2>/dev/null && FC_OPTIONS="$FC_OPTIONS -fallow-argument-mismatch"
    echo $FC_OPTIONS
    rm optiontest.f90

    to his build scripts, which will add the flag to the FC_OPTIONS
    variable if it is supported, and I thought I'd share it.

    It is certainly an MPICH issue, but I am still using gfortran version 9.2.1 just to avoid this -fallow-argument-mismatch flag when compiling MPICH for use with gfortran and OpenCoarrays. To me, it appears that this flag is somehow related to severe
    performance issues with MPICH and coarray programming. (Same issue with ifort: Intel MPI is MPICH but I can’t tell if they use a similar flag with Intel MPI).

    I did already describe my problem here: https://fortran-lang.discourse.group/t/coarrays-not-ready-for-prime-time/2715/61
    https://fortran-lang.discourse.group/t/coarrays-not-ready-for-prime-time/2715/65

    Let me add that the overall performance of a coarray program my not necessarily appear to change much when using this flag with compiling MPICH. The performance issue is slightly more subtle with my current test cases:

    - compiling MPICH without the flag (using gfortran 9.2):
    Allocating few (allocatable) coarray components takes multiple seconds (8-9 seconds on my laptop) which is of course way too slow. But then, once the coarrays are all allocated, execution of the specific parts (subtasks) with my test cases takes less
    than 0.04 second for each part. (I am using a time-out function that requires this time limit as a minimum).

    - compiling MPICH with the flag (using newer versions of gfortran or just use a recent ifort compiler version which shows the exactly same poor performance on my laptop):
    Allocating few (allocatable) coarray components is now very fast (less then 0.2 seconds on my laptop). But now execution of the specific parts (subtasks) with my test cases takes only less than 2(!) seconds for each part (time-out function requires this
    time limit as a minimum), which is way too slow for anything serious. Output on screen shows this very poor performance as well.

    Note: the shift from 0.04 second to 2 full seconds!

    Thus, my preferred setup is still using gfortran 9.2 / OpenCoarrays 2.8.0 / MPICH (3.2.1/3.4.3/4.0.1) on my laptop to already (and massively) prepare programming with Fortran for the upcoming era of (heterogeneous) spatial accelerators. To me, the
    quality of even this old (2019) gfortran/OC CAF implementation is still ahead of Intel’s ifort (which latest version I am using so far is 2021.5).

    Regards

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to Thomas Koenig on Fri Jun 17 11:16:48 2022
    On Friday, June 17, 2022 at 8:01:36 AM UTC-7, Thomas Koenig wrote:
    (snip)

    I can assure you it is not - the change in question is purely something
    that will downgrade a newly introduced error to a warning.

    Any Performance issues you are seeing may be related to the
    interplay of the OpenCoarrays library with MPICH. Since
    I know neither well, I cannot really comment on that.

    Which leaves out the question about the check itself, and whether it is
    only a compile-time test, or a run-time test.

    In any case, it could be some unrelated change in the compiler
    that happens with that version, that is causing the timing change.

    But also note, one must be very careful with any timing tests.
    For example, data in the file cache can make a program run much
    faster, not having to read it off disk. If you run program A then B,
    it might be that B runs much faster, with cached data. But run A
    again and see if the time changes.

    But timing gets even harder with multiple threads, as it depends
    on any interaction of the threads, along with everything else
    (such as the disk cache).

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From miesiehl@gmail.com@21:1/5 to Thomas Koenig on Sat Jun 18 07:14:22 2022
    Thomas Koenig schrieb am Freitag, 17. Juni 2022 um 17:01:36 UTC+2:
    mies...@gmail.com <mies...@gmail.com> schrieb:
    Thomas Koenig schrieb am Sonntag, 12. Juni 2022 um 13:53:27 UTC+2:
    I recently had an e-mail from somebody who ran into trouble
    with old code on gfortran - gfortran 9 did not have the
    -fallow-argument-mismatch flag, but gfortran 11 required it due
    to issues in the code.

    The solution I proposed was to add something like

    FC_OPTIONS="-O2"
    cat > optiontest.f90 <<EOF
    end
    EOF
    gfortran -fallow-argument-mismatch -fsyntax-only optiontest.f90 \
    /dev/null && FC_OPTIONS="$FC_OPTIONS -fallow-argument-mismatch"
    echo $FC_OPTIONS
    rm optiontest.f90

    to his build scripts, which will add the flag to the FC_OPTIONS
    variable if it is supported, and I thought I'd share it.

    It is certainly an MPICH issue, but I am still using gfortran
    version 9.2.1 just to avoid this -fallow-argument-mismatch flag
    when compiling MPICH for use with gfortran and OpenCoarrays. To me,
    it appears that this flag is somehow related to severe performance
    issues with MPICH and coarray programming.
    I can assure you it is not - the change in question is purely something
    that will downgrade a newly introduced error to a warning.

    Any Performance issues you are seeing may be related to the
    interplay of the OpenCoarrays library with MPICH. Since
    I know neither well, I cannot really comment on that.

    My personal guess is that this performance issue is not due to gfortran, not due to OpenCoarrays, and not due to ifort, but only due to MPICH. Recent releases of gfortran/OpenCoarrays and ifort show the exactly same (poor) run-time performance pattern.
    And Intel MPI is MPICH. Earlier releases of ifort did perform as fast as my setup with gfortran 9.2 and OpenCoarrays.
    And, for reasons that I can’t understand, the poor performance pattern with gfortran/OpenCoarrays occurs whenever the compilation of MPICH leads to:

    mpich 4.0.1 ./configure
    checking whether gfortran allows mismatched arguments... yes, with -fallow-argument-mismatch
    configure: error: The Fortran compiler gfortran does not accept programs that call the same routine with arguments of different types without the option -fallow-argument-mismatch. Rerun configure with FFLAGS=-fallow-argument-mismatch and FCFLAGS=-fallow-
    argument-mismatch

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From miesiehl@gmail.com@21:1/5 to mies...@gmail.com on Mon Jun 20 03:48:26 2022
    mies...@gmail.com schrieb am Samstag, 18. Juni 2022 um 16:14:29 UTC+2:
    Thomas Koenig schrieb am Freitag, 17. Juni 2022 um 17:01:36 UTC+2:
    mies...@gmail.com <mies...@gmail.com> schrieb:
    Thomas Koenig schrieb am Sonntag, 12. Juni 2022 um 13:53:27 UTC+2:
    I recently had an e-mail from somebody who ran into trouble
    with old code on gfortran - gfortran 9 did not have the
    -fallow-argument-mismatch flag, but gfortran 11 required it due
    to issues in the code.

    The solution I proposed was to add something like

    FC_OPTIONS="-O2"
    cat > optiontest.f90 <<EOF
    end
    EOF
    gfortran -fallow-argument-mismatch -fsyntax-only optiontest.f90 \
    /dev/null && FC_OPTIONS="$FC_OPTIONS -fallow-argument-mismatch"
    echo $FC_OPTIONS
    rm optiontest.f90

    to his build scripts, which will add the flag to the FC_OPTIONS
    variable if it is supported, and I thought I'd share it.

    It is certainly an MPICH issue, but I am still using gfortran
    version 9.2.1 just to avoid this -fallow-argument-mismatch flag
    when compiling MPICH for use with gfortran and OpenCoarrays. To me,
    it appears that this flag is somehow related to severe performance issues with MPICH and coarray programming.
    I can assure you it is not - the change in question is purely something that will downgrade a newly introduced error to a warning.

    Any Performance issues you are seeing may be related to the
    interplay of the OpenCoarrays library with MPICH. Since
    I know neither well, I cannot really comment on that.
    My personal guess is that this performance issue is not due to gfortran, not due to OpenCoarrays, and not due to ifort, but only due to MPICH. Recent releases of gfortran/OpenCoarrays and ifort show the exactly same (poor) run-time performance pattern.
    And Intel MPI is MPICH. Earlier releases of ifort did perform as fast as my setup with gfortran 9.2 and OpenCoarrays.
    And, for reasons that I can’t understand, the poor performance pattern with gfortran/OpenCoarrays occurs whenever the compilation of MPICH leads to:

    mpich 4.0.1 ./configure
    checking whether gfortran allows mismatched arguments... yes, with -fallow-argument-mismatch
    configure: error: The Fortran compiler gfortran does not accept programs that call the same routine with arguments of different types without the option -fallow-argument-mismatch. Rerun configure with FFLAGS=-fallow-argument-mismatch and FCFLAGS=-
    fallow-argument-mismatch

    Just to make this more complete:
    From what I did see, the poor performance pattern is not necessarily a poor performance of the image-to-image data transfers with synchronization (through MPICH), but may rather be a poor performance of executing the purely local codes (and in my case
    with oversubscribing cores, i.e. using more coarray images than hardware cores are available).

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)