Time to test this year's Intel Fortran 2020 Beta

[Ron_Green]

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!

[Michael_S_17]

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

[Ron_Green]

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

[Michael_S_17]

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

[Ron_Green]

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?

[Michael_S_17]

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.

[Michael_S_17]

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

[Juergen_R_R]

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

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

[Steve_Lionel]

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

[Ron_Green]

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

[Michael_S_17]

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

[FortranFan]

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.

[Ron_Green]

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-for-windows/topic/684930

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. 

[Ron_Green]

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.

[Michael_S_17]

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.

[Ron_Green]

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

[Michael_S_17]

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

[Michael_S_17]

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.

[Ron_Green]

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

[Michael_S_17]

I did further testing with the 19.1.0.075 Pre-Release Beta Build 20190522 using more sophisticated coarray codes.
Good news first: the coarray codes compile and run successfully, run-time behavior is virtually the same as with gfortran/OpenCoarrays.

Nevertheless, I got two new (and an old) issues with the 19.1.0.075 Pre-Release Beta Build 20190522 compiling and running more sophisticated coarray codes:

Issue #1:
Even with correct run-time behavior, I am always getting a run-time error message at program start:

Invalid character o in I_MPI_FAULT_CONTINUE

Issue #2:
Let me repeat the already known issue ‘warning #5462: Global name too long, shortened from:...’ here, because I think this could be related to issue #3 (see below). I am getting this ‘warning #5462’ always with the more sophisticated codes.

Issue #3:
Background: The programmer (1) can corrupt the coarray data transfer channels among images (usually by coding mistakes, but with my test case intentionally by setting a simple option in the code), (2) can detect such corrupted data transfer channels, and (3) can recover from such corrupted data transfer channels (by simple reallocation).

I did run my test case, both with corrupted and with non-corrupted (intact, nothing to recover from) coarray data transfer channels. Run-time behavior is as expected and virtually the same as with gfortran/OpenCoarrays, as long as I use ifort without it’s -check option.

The situation is different if I do use ifort’s -check option together with the corrupted (but not with the non-corrupted!) data transfer channel case: run-time execution fails with the following error message:
 

forrtl: severe (194): Run-Time Check Failure. The variable '00_clsparallelalgorithm_cc_mp_oooppaal00_restoresegmentorder_$INTNUMBEROFSUCCESSFULREMOTEIMAGES_' is being used in 'OOOPpaal00_clsParallelAlgorithm_CC.f90(284,7)' without being defined
In coarray image 3
Image              PC                Routine            Line        Source             
a.out              000000000040F55F  Unknown               Unknown  Unknown
a.out              000000000040E4AB  Unknown               Unknown  Unknown
a.out              00000000004134F4  Unknown               Unknown  Unknown
a.out              0000000000405232  Unknown               Unknown  Unknown
libc-2.23.so       00007F480A187830  __libc_start_main     Unknown  Unknown
a.out              0000000000405129  Unknown               Unknown  Unknown

While the variable '00_clsparallelalgorithm_cc_mp_oooppaal00_restoresegmentorder_$INTNUMBEROFSUCCESSFULREMOTEIMAGES_' from that error message is not exactly named in any of the compile time ‘warning #5462: Global name too long, shortened from:...’ error messages, it appears to me that this issue could be related to the ‘global name shortening’ issue.

Regards