Time to test this year's Intel Fortran 2020 Beta

Time to test this year's Intel Fortran 2020 Beta

Intel® Fortran Composer XE 2020 Beta

We are pleased to announce Intel® Parallel Studio XE 2020 Technical Preview Composer Edition for Fortran is ready for testing.  Packages are available for Linux*, Windows*, and macOS* X.   

These packages contain a Pre-Release version of Intel® Fortran version 19.1.  That's right, we have a "dot-1" minor release this year.  But for Fortran it's anything but minor!  This is one of our most ambitious releases to date.  We've added many Fortran 2018 features.  Get the DETAILS HERE.

When you're ready to join our test program, GO HERE to learn more and sign up!

39 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Quote:

Ronald W Green (Blackbelt) wrote:

.. We've added many Fortran 2018 features ..

Mega Kudos to Intel team on an outstanding announcement with great news on an exciting product launch, wonderful "What's New" notes as well.

Keep up the great work, 

Yep, interested in the progress. And hoping for fewer regressions this time ;)

 

The support for the Fortran Coarray collectives is great. Please also consider making Coarray Fortran interoperable with other non-Fortran MPI code. I don't know how much work that would be for Intel. But it is a very much desired feature since much of the software are mixed-language these days. Thanks for your great work @Intel and the excellent Fortran compiler.

My screen says something different: The current coarray runtime of the ifort 2020 Beta is obviously faulty. Any coarray program, even a simple one, gives a ‘BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES’. Coarray program execution itself works but start and/or end of execution is delayed.
Another problem, using OOP (inheritance) with my parallel codes did not work (the codes are running successfully with gfortran/OpenCoarrays). After some changes, the codes are now running with the ifort 2020 Beta. I am still investigating but it seems there is an issue with names (of modules and procedures) consisting of more than 31 characters (up to 63 characters are allowed since Fortran 2003) under certain circumstances. I will try to reproduce the issue with a simpler program and will then file a ticket for this via the Intel Online Service Center.

Regards

Michael, are you using x64 Configuration?  You do know that 32bit Coarrays are not working, don't you?  We're looking to remove 32bit CAF capability all together since our MPI does not support 32bit executables.

Mixing CAF and MPI:  composability - yes this has been discussed.  One important issue is the MPI_INIT() call - is it C or Fortran to make the call, as you can only call it once.  Currently Fortran has to be the main() and it calls MPI_INIT as part of startup of a CAF program. 

So since Intel MPI is based on MPICH, and iMPI is under CAF you can actually use MPI trace tools like Vampir or Intel Trace to look at communication patterns!  Also, the MPI debuggers should work.  We don't officially support this BUT .... should work. 

 

Hi Ronald,
yes I'm using the x64 configuration with Ubuntu 16.04. on a laptop. Coarray program execution does run successfully, but then the (faulty) coarray runtime ends always like this:

===================================================================================
=   BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES
=   RANK 4 PID 2988 RUNNING AT ms-P6622
=   KILLED BY SIGNAL: 9 (Killed)
===================================================================================

===================================================================================
=   BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES
=   RANK 5 PID 2989 RUNNING AT ms-P6622
=   KILLED BY SIGNAL: 9 (Killed)
===================================================================================

More severe is a heavy delay after this output before execution does terminate. (I am using SYNC ALL and ERROR STOP as last statements in my coarray program to prevent from this, so that the execution does terminate immediately). Isn't there an issue with the Intel MPI that could be the reason for this?

 

The other problem is not related or limited to coarrays, but could be caused by long names for modules and procedures: I am trying to reproduce the failure with a simple example, but this does currently not fail to execute. Nevertheless, what I currently have is this:

program main
!  use Module_Name_Does_Consist_Of_More_Than_31_Characters
  use Wants_To_Inherit_From_The_Module_With_More_Than_31_Characters
  implicit none
!  type(Type_Name_Does_Consist_Of_More_Than_31_Characters) :: TestObject
  type(Wants_To_Inherit_From_The_Type_With_More_Than_31_Characters) :: TestObject
!
  call TestObject % Procedure_Name_Does_Consist_Of_More_Than_31_Characters_external
!
end program main


module Module_Name_Does_Consist_Of_More_Than_31_Characters
!
implicit none
private
!
type, public :: Type_Name_Does_Consist_Of_More_Than_31_Characters
  private
contains
  private
  procedure, public :: Procedure_Name_Does_Consist_Of_More_Than_31_Characters_external => Procedure_Name_Does_Consist_Of_More_Than_31_Characters
end type Type_Name_Does_Consist_Of_More_Than_31_Characters
!
contains
!
subroutine Procedure_Name_Does_Consist_Of_More_Than_31_Characters (Object)
  class (Type_Name_Does_Consist_Of_More_Than_31_Characters) :: Object
  !
  write(*,*) 'Output from Procedure_Name_Does_Consist_Of_More_Than_31_Characters'
end subroutine Procedure_Name_Does_Consist_Of_More_Than_31_Characters
!
end module Module_Name_Does_Consist_Of_More_Than_31_Characters


module Wants_To_Inherit_From_The_Module_With_More_Than_31_Characters
use Module_Name_Does_Consist_Of_More_Than_31_Characters
!
implicit none
private
!
type, extends(Type_Name_Does_Consist_Of_More_Than_31_Characters), public :: Wants_To_Inherit_From_The_Type_With_More_Than_31_Characters
  private
contains
  private
end type Wants_To_Inherit_From_The_Type_With_More_Than_31_Characters
!
contains
!
end module Wants_To_Inherit_From_The_Module_With_More_Than_31_Characters

 

Compile this with ifort Module_Name_Does_Consist_Of_More_Than_31_Characters.f90 Wants_To_Inherit_From_The_Module_With_More_Than_31_Characters.f90 Main.f90 -o a.out  will give the warning message warning #5462: Global name too long, shortened from: module_name_does_consist_of_more_than_31_characters_mp_PROCEDURE_NAME_DOES_CONSIST_OF_MORE_THAN_31_CHARACTERS to: onsist_of_more_than_31_characters_mp_PROCEDURE_NAME_DOES_CONSIST_OF_MORE_THAN_31_CHARACTERS .

Therefore my question: Isn't the above code consistent with the Fortran standard's naming conventions and if so, why does ifort shorten the global name?

My original program (comming from gfortran/OpenCoarrays) did hang with ifort. After shortening the names of the Modules (and file names), and nothing else, the program does execute successfully with ifort. That is why I do expect the above warning and iforts shortening of the global names to be the reason of that failure. The above warning message can be disabled through the option -diag-disable 5462 but this does not solve the problem at all.

I will do further testing in the next few days.

Cheers

My original program (comming from gfortran/OpenCoarrays) did hang with ifort. After shortening the names of the Modules (and file names), and nothing else, the program does execute successfully with ifort.

Additionally, I did also shorten the names of the derived TYPEs.

Quote:

Ronald W Green (Blackbelt) wrote:

Michael, are you using x64 Configuration?  You do know that 32bit Coarrays are not working, don't you?  We're looking to remove 32bit CAF capability all together since our MPI does not support 32bit executables.

Ron,

Please see this thread over at the Windows forum and Quote #12 therein where Steve Lionel provides an example use of coarrays in Fortran which is far better than the Intel CAF "Hello World!" example.

Is it possible for Intel Fortran team to make Steve's example as the first test case that is used to certify the Intel Fortran compiler version for BETA or official release?!! :-))

I ask because of 2 reasons:

  1. the issue mentioned by Michael S. is easily reproducible with Steve's example (please see below) and
  2. each release of Intel Fortran compiler appears to present some basic issue or other with MPI and Intel Fortran which surfaces when coarrays are employed in Fortran code and this makes many wonder about the QA/validation process used by Intel Fortran team.

Intel Fortran team can do much better by catching the issues with MPI and coarrays well before end users ever notice them.

C:\Temp>type mcpi_coarray_final.f90
!==============================================================
!
! SAMPLE SOURCE CODE - SUBJECT TO THE TERMS OF SAMPLE CODE LICENSE AGREEMENT,
! http://software.intel.com/en-us/articles/intel-sample-source-code-license-agreement/
!
! Copyright 2016 Intel Corporation
!
! THIS FILE IS PROVIDED "AS IS" WITH NO WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
! NOT LIMITED TO ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR
! PURPOSE, NON-INFRINGEMENT OF INTELLECTUAL PROPERTY RIGHTS.
!
! =============================================================
!
! Part of the Coarray Tutorial. For information, please read
! Tutorial: Using Fortran Coarrays
! Getting Started Tutorials document

program mcpi

! This program demonstrates using Fortran coarrays to implement the classic
! method of computing the mathematical value pi using a Monte Carlo technique.
! A good explanation of this method can be found at:
! http://www.mathcs.emory.edu/~cheung/Courses/170/Syllabus/07/compute-pi.html
!
! Compiler options: /Qcoarray
!                   -coarray
!
! Note for Visual Studio users - this source is excluded from building in the
! tutorial project. If you wish to change that, right click on the file in
! Solution Explorer and select Properties. Then go to Configuration Properties >
! General. Make sure that All Configurations and All Platforms are selected, then
! change Exclude File From Build to No. Be sure to remove or exclude the sequential
! source file from the build.

implicit none

! Declare kind values for large integers, single and double precision
integer, parameter :: K_BIGINT = selected_int_kind(15)
integer, parameter :: K_DOUBLE = selected_real_kind(15,300)

! Number of trials per image. The bigger this is, the better the result
! This value must be evenly divisible by the number of images.
integer(K_BIGINT), parameter :: num_trials = 1800000000_K_BIGINT

! Actual value of PI to 18 digits for comparison
real(K_DOUBLE), parameter :: actual_pi = 3.141592653589793238_K_DOUBLE

! Declare scalar coarray that will exist on each image
integer(K_BIGINT) :: total[*] ! Per-image subtotal

! Local variables
real(K_DOUBLE) :: x,y
real(K_DOUBLE) :: computed_pi
integer :: i
integer(K_BIGINT) :: bigi
integer(K_BIGINT) :: clock_start,clock_end,clock_rate
integer, allocatable :: seed_array(:)
integer :: seed_size

! Image 1 initialization
if (THIS_IMAGE() == 1) then
    ! Make sure that num_trials is divisible by the number of images
    if (MOD(num_trials,INT(NUM_IMAGES(),K_BIGINT)) /= 0_K_BIGINT) &
        error stop "Number of trials not evenly divisible by number of images!"
    print '(A,I0,A,I0,A)', "Computing pi using ",num_trials," trials across ",NUM_IMAGES()," images"
    call SYSTEM_CLOCK(clock_start)
end if

! Set the initial random number seed to an unpredictable value, with a different
! sequence on each image. The Fortran 2015 standard specifies a new RANDOM_INIT
! intrinsic subroutine that does this, but Intel Fortran doesn't yet support it.
!
! What we do here is first call RANDOM_SEED with no arguments. The standard doesn't
! specify that behavior, but Intel Fortran sets the seed to a value based on the
! system clock. Then, because it's likely that multiple threads get the same seed,
! we modify the seed based on the image number.
call RANDOM_SEED() ! Initialize based on time
! Alter the seed values per-image
call RANDOM_SEED(seed_size) ! Get size of seed array
allocate (seed_array(seed_size))
call RANDOM_SEED(GET=seed_array) ! Get the current seed
seed_array(1) = seed_array(1) + (37*THIS_IMAGE()) ! Ignore potential overflow
call RANDOM_SEED(PUT=seed_array) ! Set the new seed

! Initialize our subtotal
total = 0_K_BIGINT

! Run the trials, with each image doing its share of the trials.
!
! Get a random X and Y and see if the position
! is within a circle of radius 1. If it is, add one to the subtotal
do bigi=1_K_BIGINT,num_trials/int(NUM_IMAGES(),K_BIGINT)
    call RANDOM_NUMBER(x)
    call RANDOM_NUMBER(y)
    if ((x*x)+(y*y) <= 1.0_K_DOUBLE) total = total + 1_K_BIGINT
end do

! Wait for everyone
sync all

! Image 1 end processing
if (this_image() == 1) then
    ! Sum all of the images' subtotals
    do i=2,num_images()
        total = total + total[i]
    end do

    ! total/num_trials is an approximation of pi/4
    computed_pi = 4.0_K_DOUBLE*(REAL(total,K_DOUBLE)/REAL(num_trials,K_DOUBLE))
    print '(A,G0.8,A,G0.3)', "Computed value of pi is ", computed_pi, &
        ", Relative Error: ",ABS((computed_pi-actual_pi)/actual_pi)
    ! Show elapsed time
    call SYSTEM_CLOCK(clock_end,clock_rate)
    print '(A,G0.3,A)', "Elapsed time is ", &
        REAL(clock_end-clock_start)/REAL(clock_rate)," seconds"
end if

end program mcpi
C:\Temp>ifort /standard-semantics /Qcoarray /Qcoarray-num-images=16 mcpi_coarray_final.f90
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 19.1.0.056 Pre-Release Beta Build 20190321
Copyright (C) 1985-2019 Intel Corporation.  All rights reserved.

ifort: NOTE: The Beta evaluation period for this product ends on 9-oct-2019 UTC.
Microsoft (R) Incremental Linker Version 14.16.27031.1
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:mcpi_coarray_final.exe
-subsystem:console
mcpi_coarray_final.obj

C:\Temp>mcpi_coarray_final.exe
Computing pi using 1800000000 trials across 16 images
Computed value of pi is 3.1415978, Relative Error: .163E-05
Elapsed time is 11.2 seconds

===================================================================================
=   BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES
=   RANK 4 PID 13976 RUNNING AT xxx
=   KILLED BY SIGNAL: -1 ()
===================================================================================

C:\Temp>mcpi_coarray_final.exe
Computing pi using 1800000000 trials across 16 images
Computed value of pi is 3.1415973, Relative Error: .149E-05
Elapsed time is 11.8 seconds

===================================================================================
=   BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES
=   RANK 4 PID 15324 RUNNING AT xxx
=   KILLED BY SIGNAL: -1 ()
===================================================================================

===================================================================================
=   BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES
=   RANK 7 PID 12612 RUNNING AT xxx
=   KILLED BY SIGNAL: -1 ()
===================================================================================

===================================================================================
=   BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES
=   RANK 11 PID 15116 RUNNING AT xxx
=   KILLED BY SIGNAL: -1 ()
===================================================================================

C:\Temp>

 

Quote:

FortranFan wrote:

 

Ron,

Please see this thread over at the Windows forum and Quote #12 therein where Steve Lionel provides an example use of coarrays in Fortran which is far better than the Intel CAF "Hello World!" example.

Is it possible for Intel Fortran team to make Steve's example as the first test case that is used to certify the Intel Fortran compiler version for BETA or official release?!! :-))

I ask because of 2 reasons:

  1. the issue mentioned by Michael S. is easily reproducible with Steve's example (please see below) and
  2. each release of Intel Fortran compiler appears to present some basic issue or other with MPI and Intel Fortran which surfaces when coarrays are employed in Fortran code and this makes many wonder about the QA/validation process used by Intel Fortran team.

Intel Fortran team can do much better by catching the issues with MPI and coarrays well before end users ever notice them.

  

 

First of all, that example IS used for testing. 

Second, i just tested it (again) with 19.1 Beta and it passed.

Computing pi using 1800000000 trials across 16 images
Computed value of pi is 3.1415939, Relative Error: .407E-06
Elapsed time is 3.39 seconds
Press any key to continue . . .

How many cores are on your system?

I have tested  on Intel(R) Xeon(R) Gold 6140 CPU @ 2.30GHz, 2295 Mhz, 18 Core(s), 36 Logical Processor(s)

 

Devorah - Intel® Developer Support

Quote:

Devorah H. (Intel) wrote:

.. How many cores are on your system?

I have tested  on Intel(R) Xeon(R) Gold 6140 CPU @ 2.30GHz, 2295 Mhz, 18 Core(s), 36 Logical Processor(s)

 

@Devorah,

The system I tested has 4 cores.  It appears the issue with "BAD TERMINATION .." occurs at a rather high frequency when /Qcoarray-num-images=n option specifies a value of n >= to the number of cores.

I suggest you retry the test on somewhat poorer hardware e.g., 4 cores like many of the users have running on their enterprise-issued low-cost, rather outdated workstations!

1>------ Rebuild All started: Project: coarray_samples, Configuration: Debug x64 ------
1>Deleting intermediate files and output files for project 'coarray_samples', configuration 'Debug|x64'.
1>Compiling with Intel(R) Visual Fortran Compiler 19.1.0.049 [Intel(R) 64]...
1>mcpi_coarray_final.f90
1>Linking...
1>Embedding manifest...
1>
1>Build log written to  "file://C:\Users\ ...coarray_samples\msvs\x64\Debug\BuildLog.htm"
1>coarray_samples - 0 error(s), 0 warning(s)
========== Rebuild All: 1 succeeded, 0 failed, 0 skipped ==========

Computing pi using 1800000000 trials across 16 images
Computed value of pi is 3.1415991, Relative Error: .206E-05
Elapsed time is 34.5 seconds
Press any key to continue . . .

Intel(R) Core(TM) i5-6300U CPU @ 2.40GHz, 2496 Mhz, 2 Core(s), 4 Logical Processor(s)

 

I still can't reproduce this issue. What is the version of Intel MPI installed on the system? Try the latest 2019 Update 4 MPI

Devorah - Intel® Developer Support

Nice..

still seems first tech preview comes with MKL, IPP ,TBB 2019 versions..

Are we getting new MKL,TBB, IPP 2020 betas integrated in next Composer 2020 betas?

I'm expecting MKL&IPP 2020 beta bring better perf. so are even more optimized libraries for IceLake..

thanks..

Quote:

Devorah H. (Intel) wrote:

.. I still can't reproduce this issue. What is the version of Intel MPI installed on the system? Try the latest 2019 Update 4 MPI

Devorah,

See below re: MPI version.  I don't know what you mean by, "Try the latest 2019 Update 4 MPI"  This workstation has Intel Fortran 19.0 compiler installed, official release onward up to Update 4.  The admin then installed 19.1 version i.e., the 2020 BETA Preview edition following the installation late week of 19.0 Update 4.  The test below is performed using the x64 script for the 2020 BETA preview version and the Intel MPI is whatever comes with the script.

C:\Temp>mpiexec -V
Intel(R) MPI Library for Windows* OS, Version 2019.0.3 Build 20190214
Copyright 2003-2019, Intel Corporation.

C:\Temp>ifort /standard-semantics /Qcoarray /Qcoarray-num-images=16 mcpi_coarray_final.f90
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 19.1.0.056 Pre-Release Beta Build 20190321
Copyright (C) 1985-2019 Intel Corporation.  All rights reserved.

Microsoft (R) Incremental Linker Version 14.16.27031.1
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:mcpi_coarray_final.exe
-subsystem:console
mcpi_coarray_final.obj

C:\Temp>mcpi_coarray_final.exe
Computing pi using 1800000000 trials across 16 images
Computed value of pi is 3.1415986, Relative Error: .189E-05
Elapsed time is 12.6 seconds

===================================================================================
=   BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES
=   RANK 11 PID 11840 RUNNING AT xxx
=   KILLED BY SIGNAL: -1 ()
===================================================================================

C:\Temp>

Note the "BAD TERMINATION .." message pops repeatedly in this environment, as shown above.  I don't know what else I can do to illustrate the issue.

Quote:

Devorah H. (Intel) wrote:

.. I still can't reproduce this issue. What is the version of Intel MPI installed on the system? Try the latest 2019 Update 4 MPI

Devorah,

See below re: MPI version.  I don't know what you mean by, "Try the latest 2019 Update 4 MPI"  This workstation has Intel Fortran 19.0 compiler installed, official release thru' Update 4.  The admin then installed 19.1 version i.e., the 2020 BETA Preview edition after the installation late week of 19.0 Update 4.  The test below is performed using the x64 script for the 2020 BETA preview version and the Intel MPI is whatever comes with the script.

C:\Temp>mpiexec -V
Intel(R) MPI Library for Windows* OS, Version 2019.0.3 Build 20190214
Copyright 2003-2019, Intel Corporation.

C:\Temp>ifort /standard-semantics /Qcoarray /Qcoarray-num-images=16 mcpi_coarray_final.f90
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 19.1.0.056 Pre-Release Beta Build 20190321
Copyright (C) 1985-2019 Intel Corporation.  All rights reserved.

Microsoft (R) Incremental Linker Version 14.16.27031.1
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:mcpi_coarray_final.exe
-subsystem:console
mcpi_coarray_final.obj

C:\Temp>mcpi_coarray_final.exe
Computing pi using 1800000000 trials across 16 images
Computed value of pi is 3.1415986, Relative Error: .189E-05
Elapsed time is 12.6 seconds

===================================================================================
=   BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES
=   RANK 11 PID 11840 RUNNING AT US36110
=   KILLED BY SIGNAL: -1 ()
===================================================================================

C:\Temp>

Note the "BAD TERMINATION .." message pops repeatedly in this environment, as shown above.  I don't know what else I can do to illustrate the issue.

Let me add:

For testing, I am using a freshly installed Linux Ubuntu 16.04 on a laptop (2 physical cores, 4 logical cores through hyperthreading). The "Bad Termination"-messages are only if I do oversubscribe the logical cores (i.e. num_images() > 4).

On the other hand, a heavy delay after coarray program execution has finished but before execution does actually terminate is always, even without oversubscribing the physical or logical cores (num_images() <= 4).

Quote:

Michael S. wrote:

Let me add:

For testing, I am using a freshly installed Linux Ubuntu 16.04 on a laptop (2 physical cores, 4 logical cores through hyperthreading). The "Bad Termination"-messages are only if I do oversubscribe the logical cores (i.e. num_images() > 4).

On the other hand, a heavy delay after coarray program execution has finished but before execution does actually terminate is always, even without oversubscribing the physical or logical cores (num_images() <= 4).

Thank you for the information I will test your issue on Linux and let you know the results.

Devorah - Intel® Developer Support

Quote:

FortranFan wrote:

Note the "BAD TERMINATION .." message pops repeatedly in this environment, as shown above.  I don't know what else I can do to illustrate the issue.

Thank you for testing it again. I will talk to the MPI team and ask them why on some systems "BAD TERMINATION" message comes up.

No luck reproducing this in similar environment: 

>mpiexec -V
Intel(R) MPI Library for Windows* OS, Version 2019.0.3 Build 20190214
Copyright 2003-2019, Intel Corporation.

>ifort /standard-semantics /Qcoarray /Qcoarray-num-images=16 mcpi_coarray_final.f90
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 19.1.0.049 Pre-Release Beta Build 20190321
Copyright (C) 1985-2019 Intel Corporation.  All rights reserved.

ifort: NOTE: The Beta evaluation period for this product ends on 9-oct-2019 UTC.
Microsoft (R) Incremental Linker Version 14.16.27030.1
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:mcpi_coarray_final.exe
-subsystem:console
mcpi_coarray_final.obj

>mcpi_coarray_final.exe
Computing pi using 1800000000 trials across 16 images
Computed value of pi is 3.1415665, Relative Error: .833E-05
Elapsed time is 28.9 seconds

>

 

Devorah - Intel® Developer Support

Answer to your message:

Hi Devorah,
these are two distinct issues:

1. The BAD TERMINATION error does not require coarray syntax, just take a simple Fortran 'Hello World' and compile it as a coarray program (and oversubscribe over the logical cores). The MPI version was installed with the 2020 Beta installer on Ubuntu. The BAD TERMINATION error can easily be reproduced by others, thus I am sure others will report that as well.

2. The issue with the SHORTEN NAMES is more tricky and I still have to investigate on it. At this time it is just a guess, but it could be that ifort's automatic shortening of the global names could corrupt the data transfer channels through (atomic) coarrays. That is what I will test for next. I will need few days to develop a simple test case for this and will then inform you, resp. directly file a ticket for this (and give the source code of the test case).

Regards

I can reproduce the BAD TERMINATION error with a very large number of images (i.e. 64), oversubscribing both on Linux and Windows. 

Regarding long names: ifort has a limit of 63, same as the standard.

Yes, it would be more efficient  and easier to track if you submit a support ticket.

Devorah - Intel® Developer Support

Regarding long names: ifort has a limit of 63, same as the standard.

Hi Devorah,

the 63 character limit of the names itself is not what I mean; This is handled by the compiler appropriate at compile time. As far as I do understand (and with my above code example) the compiler does internally combine the module name with procedure name into a new global name. Since both, module name and procedure name, can consist of up to 63 characters, this new global name could consist of up to 126 characters. (Additionally, the compiler is adding a '_mp_' between the module and procedure name, thus the global name could be up to 130 characters. 'mp' could stand for module procedure?) And that is exactly the point: the compiler does seem to automatically shorten this new global name to a maximum of 91 characters if that new global name does consist of more than 91 characters. Isn't that 91 character limit and automatic shortening of these global names to max. 91 characters itself already a possible mistake?

Cheers

Oversubscription:  Yes, this makes sense.  We have been talking to our Intel MPI people about just this topic recently.  They switched to a new fabric layer that limits oversubscription - I think it was just 2 or 4 ranks per physical cpu.  Just enough to cover hyper-threaded cores on Xeon and Xeon Phi.   I will revisit my notes.  We put in a bug report on this and have asked for the ability to oversubscribe to a larger degree.  Again, I'll revisit this and see what the results were from our conversations with that team, and our outstanding bug report.  they didn't consider the case that someone might want to prototype on a smaller workstation prior to moving production to a reasonably sized cluster.

large names:  correct <module name>_mp_<procedure name> is our decoration scheme.  And yes, "mp" is for module procedure.   Devorah can check in on internal limits on decorated names.  I have run into this on the PGI compiler in the recent past.  Fortunately I didn't get truncated name collisions but it is quite possible to get collisions if one is not careful.  In any case let's see what that limit is and see if we can nudge the decorated name size limit out further.  It does slow compilation which is why compiler vendors try to put limits on symbol sizes (string matches take longer for longer strings).

Ron

Ron, Devorah,
after doing some further testing, I want to inform you that the LARGE NAMES issue did not cause my example program to fail. My LARGE NAMES codes are now successfully running with the ifort Beta. Instead it was my own fault, even if I can't say exactly what the mistake was. (The codes were originally developed with gfortran/OpenCoarrays. I had to adapt them for usage with ifort because the original codes are already using F18 coarray teams).
Therefore, I will not file a ticket for that LARGE NAMES issue myself.

What remains is the issue with oversubscription (over the logical cores available): The heavy delay after coarray program execution is serious because it may prevent using ifort for development of coarray framework codes on a laptop computer or other non-HPC machines. Development of coarray framework codes itself does not require to do much local computations: With current gfortran/OpenCoararys/MPICH we can (heavily) oversubscribe and still have very fast execution on a laptop with such coarray framework codes.
I'd further say that development of such coarray framework codes (to extend Fortran's basic coarray model) is currently most important to already prepare for the exascale.

Regards

Michael, we are investigating the long names issue.

On the oversubscription issue - how deeply are you oversubscribing currently with gfortran?  2x would be 2 images per PHYSICAL core, that is, using the physical core and it's 1 hyperthreaded context.  4x would be 4 images per physical core. 

So where are you today with oversubscription? 4x, 5x, 6x or what?

Similarly, up to what oversubscription level would you anticipate as your maximum need?

Ron, from using gfortran/OpenCoarrays/MPICH:

Well, I did not try out how far we can go but 12 images on a dual core with hyperthreading enabled and in use (4 logical cores) is no problem at all for executing sophisticated parallel logic codes successfully. (I do so with only very few local computation). I think 24 images on such a dual core should be no problem as well. The maximum I did try with OpenCoarrays/gfortran on that dual core was 50 (or 100?) images. (But I did not try running parallel logical codes on so many oversubscribed images, instead did run the logic codes successfully on only fewer of the 50 images.)

With that, speed doesn't really matter. What is important (and a big surprise) instead, even if we do execute such a number of images on so few physical and logical cores, the data transfer channels (through coarrays) between the distinct images remain completely independent. To fully understand you need coarray teams: If we do corrupt the data transfer channels of atomics in one team, the data transfer channels of the same atomics (through the same declaration statement) remain intact within the other coarray teams (which do execute on the same core!). In a way, the coarray runtime does perfectly emulate a full featured HPC machine (in much lower scale of course). To me, that came as the biggest surprise and is why I can do coarray framework development on a laptop.

 

I did just check the ifort 2020 beta with coarray components, but the compiler does seem to reject coarray components as actual arguments with a procedure call:

OOOPessy00_clsEventScalarSync_CC.f90(145): error #8396: If the dummy argument is a coarray, the corresponding actual argument must be a coarray and must have the VOLATILE attribute if and only if the dummy argument has the VOLATILE attribute.   [OOOPIMSCCOARRAYCOMPONENT_CC]
  call OOOPimsc_subSyncMemory (Object % OOOPimscCoarrayComponent_CC)
----------------------------------------^

Can someone confirm this behavior of the compiler? I think this must must be a bug. The codes are successfully working with gfortran/OpenCoarrays.

Regards

Can you show the code? Or point to a link?

Quote:

Michael S. wrote:

I did just check the ifort 2020 beta with coarray components, but the compiler does seem to reject coarray components as actual arguments with a procedure call:

OOOPessy00_clsEventScalarSync_CC.f90(145): error #8396: If the dummy argument is a coarray, the corresponding actual argument must be a coarray and must have the VOLATILE attribute if and only if the dummy argument has the VOLATILE attribute.   [OOOPIMSCCOARRAYCOMPONENT_CC]
  call OOOPimsc_subSyncMemory (Object % OOOPimscCoarrayComponent_CC)
----------------------------------------^

Can someone confirm this behavior of the compiler? I think this must must be a bug. The codes are successfully working with gfortran/OpenCoarrays.

Regards

Here's a test. It fails as noted with 19.0 - haven't tried 19.1 yet. As far as I can tell, this is valid F2008.

type mytype
  integer, allocatable, codimension[:] :: c
  end type mytype
  
type(mytype) :: a

call foo (a%c)

contains

subroutine foo (c)
integer, codimension[*] :: c
end subroutine foo

end

 

Steve (aka "Doctor Fortran") - Retired from Intel

This is fixed in 19.1.  I used the PSXE 2020 Technology Preview 19.1 compiler to test and it's fixed.  Also tested a nightly build of 19.1 and it's fixed.

HOWEVER it will still be broken in the upcoming 2019 Update 5 compiler due to release any day now.

Thank you for a great reproducer, Doctor Fortran

Ron

The following simple test case does compile with gfortran/OpenCoarrays. Does this also compile with ifort? (Currently, I don't have access to ifort):

program Main
! nothing here
end program Main

module CoarrayWrapperModule
use, intrinsic :: iso_fortran_env
implicit none
private
public :: CoarrayWrapperRoutine
!
type, public :: CoarrayWrapperType
  private
  integer(atomic_int_kind) :: m_atomic_intMember
end type CoarrayWrapperType
!
contains
!
subroutine CoarrayWrapperRoutine (Object_CA)
  type (CoarrayWrapperType), codimension[*], intent (inout) :: Object_CA
! do something here
end subroutine CoarrayWrapperRoutine
!
end module CoarrayWrapperModule

module CoarrayComponent
use CoarrayWrapperModule
use, intrinsic :: iso_fortran_env
implicit none
private
!
type, abstract, public :: CoarrayComponentType
  private
  ! coarray component:
  type (CoarrayWrapperType), public, codimension[:], allocatable :: CoarrayComponent
  !
contains
  private
  procedure, public :: CoarrayComponentRoutine => P00_CoarrayComponentRoutine
  !
end type CoarrayComponentType
!
!****
contains
!
subroutine P00_CoarrayComponentRoutine (Object)
  class (CoarrayComponentType), intent (inout) :: Object
  !
  call CoarrayWrapperRoutine (Object % CoarrayComponent)
  !
end subroutine P00_CoarrayComponentRoutine
!
end module CoarrayComponent

 

Quote:

Michael S. wrote:

The following simple test case does compile with gfortran/OpenCoarrays. Does this also compile with ifort? ..

How's this example different from Steve's example in Quote #29?  It appears the comments by Ronald W Green (Blackbelt) in Quote #30 would apply.

 

It does compile BUT there is a warning about the resulting symbol name being too long:

$ ifort -coarray repro2.f90 

repro2.f90(1): warning #5462: Global name too long, shortened from: coarraycomponent_$coarraywrappermodule_.coarraycomponent$.btcoarraycomponenttype$coarraycomponent

to:

oarraycomponent_$coarraywrappermodule_.coarraycomponent$.btcoarraycomponenttype$coarraycomponent

 

Steve researched a similar issue a few years back:  https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-fo...

it's interesting.  Keep in mind this is a WARNING level, could be ignored or masked.  It does create an a.out.  I am not sure what to do about the long symbol name.  Please read the Forum reference above.  I will bring this up at the next team meeting. 

the 19.1 compiler is still available, see the links at the top of this thread.

but it's soon to go offline.  And the license expires in early/mid October 2019.  This 19.1 compiler will be released in late November.  I'll post a notice about the release date.

Thanks for checking this. I did just re-check myself with my above code example (keeping the codes in three distinct code files) and ifort version 19.1.0.056 Beta , but again got the following compile time error:

OOOPessy00_clsEventScalarSync_CC.f90(25): error #8396: If the dummy argument is a coarray, the corresponding actual argument must be a coarray and must have the VOLATILE attribute if and only if the dummy argument has the VOLATILE attribute.   [COARRAYCOMPONENT]
  call CoarrayWrapperRoutine (Object % CoarrayComponent)
---------------------------------------^

Maybe that has been resolved in a more recent version of ifort 19.1?

To mask the 'Global name too long'-warning we can use the ifort -diag-disable 5462 option. But I did not get that warning message myself yet.

Yes, you have the original beta/tech preview release.  I used the beta/tech preview UPDATE 1:

ifort -V

Intel(R) Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 19.1.0.075 Pre-Release Beta Build 20190522

you are using

Intel(R) Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 19.1.0.056 Pre-Release Beta Build 20190321

 

You can download the Update 1 from https://registrationcenter.intel.com with your account.

Ron

 

Ron,
thanks very much, I'll download Update 1 for further testing. I am currently investigating another bug with gfortran/OpenCoarrays -it's a problem with atomic subroutines there- and wanted to check if ifort could handle the failing code.

cheers

It does compile BUT there is a warning about the resulting symbol name being too long:

$ ifort -coarray repro2.f90 

repro2.f90(1): warning #5462: Global name too long, shortened from: coarraycomponent_$coarraywrappermodule_.coarraycomponent$.btcoarraycomponenttype$coarraycomponent

to:

oarraycomponent_$coarraywrappermodule_.coarraycomponent$.btcoarraycomponenttype$coarraycomponent

This time I did use the Intel(R) Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 19.1.0.075 Pre-Release Beta Build 20190522 and it works perfectly with the code example. I did not even get yours above warning #5462. I will do some further testing with other codes as well.

Nevertheless, for true lift-off the compiler needs support for coarray teams in the near future.

Coarray teams is on our "to-do" list for sure. 

Leave a Comment

Please sign in to add a comment. Not a member? Join today