Implementation of unlimited polymorphic types

[Nicholas_B_]

How are unlimited polymorphic types implemented in Intel Fortran?

The obvious impolementation would be as two C poiinters, one pointing to a structure describing the target type and the other pointing to the target data.

It looks like gfortran uses this appproach: https://gcc.gnu.org/wiki/OOP#Internal_Representation

With this approach I would expect the following types to have the same storage size:

  type class_ptr_type
    class(*), pointer :: ptr => null()
  end type class_ptr_type

  type class_cptr_type
    type(c_ptr) :: data_type = c_null_ptr
    type(c_ptr) :: data = c_null_ptr
  end type class_cptr_type

With Intel Fortran the types have storage sizes of 16 words and 2 words respectively.

With gfortran 4.9.2 the both have storage sizes of 2 words.

Does Intel Fortran include a structure describing the type in every type(class_ptr_type) object?

I can see that this may avoid one pointer dereference and may have better cache usage poperties but the 8x increase in storage seems a high price to pay.

The attached code illlustrates the use of these types.

Nick

[Steven_L_Intel1]

It would be impossible to describe every possible type. However, we have a single "extended descriptor" and don't have a separate implementation for class(*) pointers. This descriptor, when filled in, has pointers to additional information about the types. Offhand I don't know what all the fields are.

[Nicholas_B_]

Steve,

Thank you for your reply.

In my current use case it probably does not matter that Intel Fortran is using 8 times as much storage for the class(*) pointer as gfortran (128 bytes vs 16 bytes) becuase the objects I want to point to will be thousands to milliions of bytes. The most extreme case I can think of is pointing to objects which occupy 4 bytes in which case Intel Fortran would use 128+4 = 132 bytes per item compared to 16+4 = 20 bytes per item for gfortran (6.6 times more storage).

I think most, if not all, Fortran compilers are at the point where getting all Fortran 2008 features to work is higher priority than performance but I suspect that it would be possible to devise a benchmark program based on the above which showed gfortran being a lot faster than Intel Fortran. I think it would be a good idea for Intel to change the implementation of scalar polymorphic pointers (class(x), pointer) before they are used too much and before they start appearing in the public interfaces to libraries. (Having to recompile all code which uses 'class(x), pointer' is less of an issue now than it would be when much more code uses the feature).

The attached code demonstrates the issue:

Intel Fortran 16.0.1 x64:

 Size of type(c_ptr) (1 word):  64  bits
 Size of class(*), pointer:     16  words

gfotran 4.9.2 x64:

 Size of type(c_ptr) (1 word):  64  bits
 Size of class(*), pointer:     2  words

Regards

Nick

[Nicholas_B_]

I accidently uploaded the file in Unix format. Here is the DOS format version.

[Nicholas_B_]

Footnote: Actually the most exteme case is where every item is a null pointer (Intel Fortran uses 8 times as much storage as gfortran).

[Steven_L_Intel1]

If we see a real application, not an artificially constructed test, that indicates a performance problem, we'll be glad to look at it. So far we aren't seeing any real effect of larger descriptors, and we're not lacking for things to work on.

That said, you're right that attention needs to be paid to optimizing the new language features. The Fortran world has been through this before, with array operations being slower than DO loops in the early days of Fortran 90. OOP is always going to be slower due to information deferred to run-time, but that doesn't mean we can't try to make it better. 

[FortranFan]

Nicholas B. wrote:

.. it would be possible to devise a benchmark program based on the above which showed gfortran being a lot faster than Intel Fortran. I think it would be a good idea for Intel to change the implementation of scalar polymorphic pointers (class(x), pointer) before they are used too much ..

I'll be keen to see a meaningful benchmark test that truly illustrates performance differences due to manner of compiler implementation of derived types and/or (unlimited) polymorphic pointers, so appreciate it if you can devise one and post it here.

[Nicholas_B_]

Here is a benchmark program.

It is meant to show multiplying a complex vector by a block diagonal matrix in which most blocks are diagonal real matrices which are multiples of the identity matrix but a few blocks are general complex matrices with only a few distinct values for the blocks.

The Intel compiler 16.0.1 (x64) with options /O2 /QxHost gives the following output on my Windows 10 x64 laptop gives:

 storage size of a =    2.560000     MB
 storage size of x =    1.280000     MB
 elapsed time =    2.35500000000000      s

gfortran 4.9.2 with options -O -march=native on a virtual machine running CentOS 7 x64 on the same laptop gives:

 storage size of a =   0.319999993     MB
 storage size of x =    1.27999997     MB
 elapsed time =    1.8063516970000000      s