Runtime overhead of using CLASS and TYPE-BOUND PROCEDURE

[ojacquet]

1      Introduction

There are very few sources of information to understand how object-oriented programming with the Fortran language would induce significant performance degradations. However, this question is often asked or addressed in forums and the answers of the "most experts" often consist of saying that object-oriented programming:

• is not correctly mastered and implemented,
• does not enormously penalize the calculations,
• has many other benefits that compensate for performance degradation.

These answers are not really convincing for those who place a high value on computational times, especially those who develop scientific computing programs. Moreover, these questions do not seem to arise with the C++ language. This raises the question of whether object-oriented programming in Fortran has been used extensively in real scientific computing codes and whether it is not discarded in the most critical parts of the code from the point of view of computation time.

In 2011, the user thomas_boehme of the Intel Fortran compiler created a topic on this forum: Runtime overhead of using CLASS dummy arguments. He asked for help with the degradations caused by the use of classes and type-bound procedures. The problem observed was highlighted by a simple test program.

Based on this test program, two more comprehensive Fortran programs have been written.

The version of the Intel Fortran compiler used for these tests is as follows: ifort (IFORT) 2021.10.0 20230609

2      Conducting Tests

2.1     Fortran Test Program No. 1

2.1.1    Description

The program, given in file test1.f90, is based on the MyType type, defined with a single Val field of type real(8) and several attached procedures (type-bound procedures):

• ClassArgAdd,
• ClassArgEncapsTypeArgAdd,
• ClassArgEncapsClassArgAdd,
• ClassArgEncapsTbpClassArgAdd (only when the preprocessor group1 macro is greater than or equal to 4 or when the preprocessor calc macro is 112 or 212).

Different routines are defined, calculating the sum of two variables:

• TypeArgAdd: has arguments A and B of type: type(MyType) and calculates the sum of the Val fields of the two variables:

A%Val = A%Val + B%Val

• ClassArgAdd: has arguments A and B of type: class(MyType) and calculates the sum of the Val fields of the two variables:

A%Val = A%Val + B%Val

• TypeArgEncapsTypeArgAdd: has arguments A and B of type: type(MyType) and calls the TypeArgAdd routine in the standard way:

CALL TypeArgAdd(A,B)

• TypeArgEncapsClassArgAdd: has arguments A and B of type: type(MyType) and calls the ClassArgAdd routine in the standard way:

CALL ClassArgAdd(A,B)

• TypeArgEncapsTbpClassArgAdd: has arguments of type: type(MyType) and calls the ClassArgAdd routine as a type-bound procedure:

CALL A%ClassArgAdd(B)

• ClassArgEncapsTypeArgAdd: has arguments A and B of type: class(MyType) and calls the TypeArgAdd routine in the standard way:

CALL TypeArgAdd(A,B)

• ClassArgEncapsClassArgAdd: has arguments A and B of type: class(MyType) and calls the ClassArgAdd routine in the standard way:

CALL ClassArgAdd(A,B)

• ClassArgEncapsTbpClassArgAdd: has arguments A and B of type: class(MyType) and calls the ClassArgAdd routine as a type-bound procedure:

CALL A%ClassArgAdd(B)

The latter routine is defined only when the preprocessor's group1 macro is greater than or equal to 2 or when the preprocessor's calc macro is 111, 112, 211, or 212).

26 elementary calculations are defined, theoretically equivalent, consisting of the realization of 1010 sums realized as follows:

• 100 and 200: direct summation of the Val fields of the two variables,
• 101 and 201: call the TypeArgAdd routine,
• 102 and 202: call the ClassArgAdd routine in the standard way,
• 103 and 203: call the ClassArgAdd routine as a type-bound procedure,
• 104 and 204: Call the TypeArgEncapsTypeArgAdd routine,
• 105 and 205: Call the TypeArgEncapsClassArgAdd routine,
• 106 and 206: call the TypeArgEncapsTbpClassArgAdd routine,
• 107 and 207: Call the ClassArgEncapsTypeArgAdd routine in the standard way.
• 108 and 208: Call the ClassArgEncapsTypeArgAdd routine as a type-bound procedure.
• 109 and 209: call the ClassArgEncapsClassArgAdd routine in the standard way,
• 110 and 210: Call the ClassArgEncapsClassArgAdd routine as a type-bound procedure.
• 111 and 211: Call the ClassArgEncapsTbpClassArgAdd routine in the standard way.
• 112 and 212: Call the ClassArgEncapsTbpClassArgAdd routine as a type-bound procedure.

Elementary calculations 100 to 112 operate on two variables declared with the type: type(MyType).

Elementary calculations 200 to 212 operate on two variables declared with the type: class(MyType), allocatable, and allocated with the type: type(MyType).

2.1.2    Elementary calculations

Initially, each elementary calculation is carried out separately.

To do this, the test1.f90 file is compiled:

• by assigning the calc macro used by the preprocessor the id of the elementary calculation (from 100 to 112 and from 200 to 212): -fpp -Dcalc=id
• with each of the following four compilation option combinations:
  • -O2
  • -O2 -ip
  • -O2 -ipo
  • -O2 -ipo -ip

The CPU times of each elementary calculation are given in the Table 1 according to an arbitrary time unit: the computation times were divided by the lowest time obtained.

It appears that:

• The vast majority of elementary calculations, regardless of the compilation option used, have a performance equivalent to the most direct calculation.
• The -O2 compilation option has the worst performance on some elementary calculations.
• The -ip and -ipo compilation options, combined with the -O2 option, significantly improve performance, the -ipo option being the more advantageous of the two. The combination of the -ip and -ipo options does not provide any improvement over the -ipo option.
• Calculations 112 and 212, both of which call the ClassArgEncapsTbpClassArgAdd routine as a type-bound procedure, are significantly slower than the others. This routine itself calls the ClassArgAdd routine as a type-bound procedure.

Table 1 : Test No. 1. Computational time of separate elementary calculations (arbitrary unit)

2.1.3    Grouped calculations 1

In a second step, the elementary calculations are carried out in a grouped manner.

To do this, the test1.f90 file is compiled:

• By setting the group1 macro used by the preprocessor to a value of 1 to 5, which as it increases, allows more calculations to be included:
  • -fpp -Dgroup1=1: Elementary calculations 100 to 110 and 200 to 210,
  • -fpp -Dgroup1=2: Elementary calculations 100 to 111 and 200 to 210 – added calculation 111 and definition of the ClassArgEncapsTbpClassArgAdd routine,
  • -fpp -Dgroup1=3: Elementary calculations 100 to 111 and 200 to 211 – addition of calculation 211,
  • -fpp -Dgroup1=4: Elementary calculations 100 to 111 and 200 to 211 – added the ClassArgEncapsTbpClassArgAdd routine to the MyType type,
  • -fpp -Dgroup1=5: Elementary calculations 100 to 112 and 200 to 212 – added calculations 112 and 212.
• with each of the following four compilation option combinations:
  • -O2
  • -O2 -ip
  • -O2 -ipo
  • -O2 -ipo -ip

For the 5 * 4 = 20 calculations grouped together, the CPU times of each elementary calculation is given in the Table 2 according to an arbitrary time unit: the computation times were divided by the lowest time obtained.

It appears that:

• The performance of elementary calculations, when grouped together in a single calculation, can be degraded compared to the separate calculations.

• With the -O2 compilation option, the degradation due to the grouping of calculations affects all but the most direct calculations (elementary calculations 100 and 200).

• With the compilation options -O2 and -ip combined, the degradation due to the grouping of calculations occurs from group1=3 (i.e. when elementary calculation 211 is added) and concerns elementary calculations 201 to 210 (with variables of type class), whose computation time increases from 1 to a value between 1.6 and 2.3.

• With the -O2 and -ipo compilation options combined, the degradation due to the grouping of calculations occurs from group1=4 (i.e. when the ClassArgEncapsTbpClassArgAdd routine is attached as a procedure to the MyType type) and involves:
  • elementary calculation 111 (with variables of type (MyType)), whose computation time increases from 1 to 7.5,
  • elementary calculations 201 to 211 (with variables of type class(MyType)), whose computation time increases from 1 to a value between 1.6 and 2.4.

In summary, the facts that are of concern are the following:

• Adding some calculations may degrade the performance of other calculations.
• Attaching a procedure to a type can degrade the performance of computations that use that type but do not use that procedure.

Table 2 : Test No. 1. Computational time of grouped elementary calculations 1 (arbitrary unit)

2.1.4    Grouped calculations 2

In the third step, the elementary calculations are still performed in a group manner but only with the -O2 compilation option.

To do this, the test1.f90 file is compiled:

• by assigning the group2 macro used by the preprocessor a value from 1 to 6, which allows different calculations to be included in a specific order:
  • -fpp -Dgroup2=1: Elementary calculations 100, 102 to 105, 109, 110, 200, 202 to 205, 209 and 210,
  • -fpp -Dgroup2=2: Elementary calculations 100 to 105, 109, 110, 200 to 205, 209 and 210 – addition of calculations 101 and 201 to calculation 1,
  • -fpp -Dgroup2=3: Elementary calculations 100, 102 to 106, 109, 110, 200, 202 to 206, 209 and 210 – addition of calculations 106 and 206 to calculation 1,
  • -fpp -Dgroup2=4: Elementary calculations 100, 102 to 104, 109, 110, 105, 106, 200, 202 to 204, 209, 210, 205 and 206 – moved calculations 105, 106, 205 and 206 from calculation 2,
  • -fpp -Dgroup2=5: Elementary calculations 100 to 104, 109, 110, 105, 106, 200, 202 to 204, 209, 210, 205 and 206 – addition of calculation 101 to calculation 4,
  • -fpp -Dgroup1=6: Elementary calculations 100 to 104, 109, 110, 105, 106, 200 to 204, 209, 210, 205 and 206 – addition of calculation 201 to calculation 5,
• only with the -O2 compilation option.

For the 6 grouped calculations, the CPU times of each elementary calculation are given in the Table 3 according to an arbitrary time unit: the computation times were divided by the lowest time obtained.

It appears that:

• Calculation 2: Adding calculations 101 and 201 to calculation 1 results in an increase in the time of calculations 105 and 205.

• Calculation 3: Adding calculations 106 and 206 to calculation 1 also results in an increase in the time taken to calculate 105 and 205.

• Calculation 4: Moving calculations 105 and 206 after calculation 110 and calculations 205 and 206 after calculation 210 results in a decrease in the time of calculations 106 and 206.

• Calculation 5: Adding calculation 101 to calculation 4 does not result in any changes.

• Calculation 6: The addition of calculation 201 to calculation 5 results in a very large increase in the time of calculations 109 and 110 and a significant increase in the time of calculation 209.

In summary, the facts that are of concern are the following:

• Adding some calculations may degrade the performance of other calculations.
• Changing the order of some calculations can degrade or improve the performance of other calculations.

Table 3 : Test No. 1. Computational time of grouped elementary calculations 2 (arbitrary unit)

2.2     Fortran Test Program No. 2

2.2.1    Description

The program, given in file test2.f90, aims to test a situation closer to the cases encountered in practice, i.e. a first type to which procedures are attached, used to define a field in a second type to which procedures are attached that call procedures related to the first type.

As in test program 1, the first type is the MyType type, defined with a single Val field of type real(8) and two attached procedures (type-bound procedures):

• ClassArgAdd,
• ClassArgEncapsClassArgAdd.

Five wraparound types are defined containing a single Data field:

• WrapTType, whose Data field is type: type(MyType),
• WrapTPType, whose Data field is of type: type(MyType), pointer,
• WrapTAType, whose Data field is of type: type(MyType), allocatable,
• WrapCPType, whose Data field is of type: class(MyType), pointer,
• WrapCAType, whose Data field is of type: class(MyType), allocatable.

In the future, the letter X may be replaced by T, TP, TA, CP and CA in the generic names of types and procedures.

Each of these 5 types wraps WrapXType have 5 procedures attached:

• WrapDirectAdd pointing to the WrapXDirectAdd routine,
• WrapClassArgAdd pointing to the WrapXClassArgAdd routine,
• WrapTbpClassArgAdd pointing to the WrapXTbpClassArgAdd routine (only when the preprocessor's wraptbp macro is set),
• WrapClassArgEncapsClassArgAdd pointing to the WrapXClassArgEncapsClassArgAdd routine,
• WrapTbpClassArgEncapsClassArgAdd pointing to the WrapXTbpClassArgEncapsClassArgAdd routine (only when the preprocessor's wraptbp macro is set).

Different routines are defined, calculating the sum of two variables:

• ClassArgAdd: has arguments A and B of type: class(MyType) and calculates the sum of the Val fields of the two variables:

A%Val = A%Val + B%Val

• ClassArgEncapsClassArgAdd: has arguments A and B of type: class(MyType) and calls the ClassArgAdd routine:
  • as a type-bound procedure:

CALL A%ClassArgAdd(B)

• • Standard:

CALL ClassArgAdd(A,B)

depending on whether the preprocessor's encapstbp macro is set or not.

• WrapXDirectAdd: has arguments A and B of type: class(WrapXType) and calculates the sum of the Val fields of the Data fields of the two variables:

A%Data%Val = A%Data%Val + B%Data%Val

• WrapXClassArgAdd has arguments A and B of type: class(WrapXType) and calls the ClassArgAdd routine in the standard way:

CALL ClassArgAdd(A%Data,B%Data)

• WrapXTbpClassArgAdd has arguments A and B of type: class(WrapXType) and calls the ClassArgAdd routine as a type-bound procedure:

CALL A%Data%ClassArgAdd(B%Data)

• WrapXClassArgEncapsClassArgAdd has arguments A and B of type: class(WrapXType) and calls the ClassArgEncapsClassArgAdd routine in the standard way:

CALL ClassArgEncapsClassArgAdd(A%Data,B%Data)

• WrapXTbpClassArgEncapsClassArgAdd has arguments A and B of type: class(WrapXType) and calls the ClassArgEncapsClassArgAdd routine as a type-bound procedure:

CALL A%Data%ClassArgEncapsClassArgAdd(B%Data)

125 elementary calculations are defined, theoretically equivalent, consisting of the realization of 109 sums realized as follows:

• xy1: Call the WrapDirectAdd routine as a type-bound procedure.
• xy2: Call the WrapClassArgAdd routine as a type-bound procedure.
• xy3: Call the WrapTbpClassArgAdd routine as a type-bound procedure.
• xy4: Call the WrapClassArgEncapsClassArgAdd routine as a type-bound procedure.
• xy5: Calling the WrapTbpClassArgEncapsClassArgAdd routine as a type-bound procedure.

Where:

• x takes the values 1 to 5:
  • 1: the type tested is the type WrapXType = WrapTType,
  • 2: the type tested is the type WrapXType = WrapTPType,
  • 3: the type tested is the type WrapXType = WrapTAType,
  • 4: the type tested is the type WrapXType = WrapCPType,
  • 5: The type tested is the type WrapXType = WrapCAType.
• y takes the values 1 to 5:
  • 1: the variables used are of type: type(WrapXType),
  • 2: the variables used are of type: type(WrapXType), pointer,
  • 3: the variables used are: type(WrapXType), allocatable,
  • 4: the variables used are: class(WrapXType), pointer,
  • 5: The variables used are of type: class(WrapXType), allocatable.

2.2.2    Elementary calculations

Initially, each elementary calculation is carried out separately.

To do this, the test2.f90 file is compiled:

• by assigning the calc macro used by the preprocessor the id identifier of the elementary calculation (xyz where x, y, and z vary from 1 to 5): -fpp -Dcalc=id
• Setting or not defining the encapstbp macro used by the preprocessor, modifying the definition of the ClassArgEncapsClassArgAdd routine (calling the ClassArgAdd routine as a type-bound procedure or in a standard way),
• with only one combination of compilation options: -O2 -ipo -ip

The CPU times of each elementary calculation are given in the Table 4 according to an arbitrary time unit: the computation times were divided by the lowest time obtained.

It appears that:

• the vast majority of elementary calculations have a performance equivalent to the most direct calculation,
• computations involving data fields of type class (pointer or allocatable) have seriously degraded performance (time from 10.5 to 13.5), when using routines calling other routines such as type-bound procedures,
• calculations involving Data fields of type type have degraded performance (time of the order of 1.6), when the variables used are themselves declared as type (calculations 112 to 115),
• Calculations based on the ClassArgEncapsClassArgAdd routine have very degraded performance (time of the order of 7.5 for x=1,2,3) or degraded performance (time of the order of 2.3 for x=4.5) when it calls the ClassArgAdd routine as a type-bound procedure (calculations xy4 and xy5 with encapstbp=1).

Table 4 : Test No. 2. Computational time of separate elementary calculations (arbitrary unit)

2.2.3    Grouped calculations

In a second step, the elementary calculations are carried out in a grouped manner.

To do this, the test2.f90 file is compiled:

• Setting or not defining the encapstbp macro used by the preprocessor, modifying the definition of the ClassArgEncapsClassArgAdd routine (calling the ClassArgAdd routine as a type-bound procedure or in a standard way),
• whether or not to set the wraptbp macro used by the preprocessor (which has the effect of keeping or eliminating the definition of the WrapXTbpClassArgAdd and WrapXTbpClassArgEncapsClassArgAdd routines as well as the calculations based on the call to these routines; the particularity of these routines being to call the ClassArgAdd and ClassArgEncapsClassArgAdd routines respectively as a type-bound procedure),
• with only one combination of compilation options: -O2 -ipo -ip

For the 4 grouped calculations, the CPU times of each elementary calculation are given in the Table 5 according to an arbitrary time unit: the computation times were divided by the lowest time obtained.

It appears that:

• The performance of elementary calculations, when grouped together in the same calculation, can be degraded or even very degraded compared to the separate calculation.

• Depending on the type of variables used and the type of field, the behaviors are very diverse and this complexity is problematic or even inconsistent and therefore suspicious.

• The use of type-bound procedures within routines that are themselves called type-bound procedures is very penalizing and can even impact the performance of calculations that do not use these type-bound procedures.

• Using type-bound procedures for a field within a type-bound procedure is very penalizing. This seems contradictory to the philosophy of object-oriented programming.

Table 5 : Test No. 2. Computational time of grouped elementary calculations (arbitrary unit)

3      Conclusion

At the conclusion of the tests carried out, the unresolved questions are:

• Is it acceptable for the performance of one part of a program to be modified by the addition or displacement of another part, which a priori does not have a direct link with the first part (the only link being the fact that they use the same type)?
• What is the benefit of a type-bound procedure if performance is seriously degraded if it is used in another type-bound procedure? Isn't this at odds with the philosophy of object-oriented programming?
• Are all these behaviours in line with the recommendations of the standard?
• Are they due to an anomaly or a design flaw in the compiler? Can the compiler be improved?

[ojacquet]

Thank you Jim.

>>Barring the above, wait for the compiler development to correct the issue.

Do you think the different issues are now taken into account by the compiler development? Or is there a procedure to follow for that?

Olivier

[JohnNichols]

Usually you can submit a ticket if you have paid support,  good method,  wait for one of the moderators to say they noticed the problem and tell you they raised a ticket, or send one them a personal email using the private Intel system. 

On Monday, I would take step 3 at least they will tell you 

1. they are interested or it is

2. impossible to solve or 

3. they are praying to the Fortran gods for inspiration. 

The last one often appears to be the controlling factor in Fortran. 

Fortran does not move quickly, that is the advantage and disadvantage.  

[jimdempseyatthecove]

I would think that this issue is low in the priority of things to address.

Bugs first, features second, performance third.

Eventually it will get fixed.

Jim Dempsey

[andrew_4619]

Almost, a slightly modified priority:

Bugs first, features second, new bugs third, performance fourth, new bugs fifth!!

[JohnNichols]

A man of humour.  

As a collective group, we can consider ourselves as pickets.

From NC Wyeth book of poems and in the public domain.  

We are waiting for bugs and a lot of them are not and so Intel gets free first line of defense. 

[ojacquet]

Apparently, no one at Intel has read or is interested in the topic.

Or is Intel waiting for me to make a support request?

Is this necessary if there is a glaring problem with the compiler?

Not knowing how to get in touch with someone from Intel, if someone, who shares the same interest as me in making the compiler work better, has the option to report the problem to Intel themselves, that would be nice.

Thank you very much.

[andrew_4619]

So many data tables, but to study and understand is a project! Is is clear that some code/constructs are slow than others. It is clear that some code could have better optimisation but this seems quite general and abstract. What is that that you area really asking of Intel I personal am not clear in that, maybe that is just me....

[ojacquet]

Andrew,
Have you read my second post:
https://community.intel.com/t5/Intel-Fortran-Compiler/Runtime-overhead-of-using-CLASS-and-TYPE-BOUND-PROCEDURE/m-p/1542274#M169074

It's less complex that the first one. It explains how to reproduce the results and how the tables are built.

Do you think normal that computational time can be multiplied by factors between 2 and 20 for calculations that should be equivalent?

Do you think normal that a type bound procedure nested in another one degrades performances drastically? It removes all the interest of such functionnality.

Do you think normal that pieces of program have better performances when they are run separately than when they are run in the same program, or that their performance can be modified when they are run in a different order?

[andrew_4619]

Sorry I am not wanting to have a 'fight' over this I was just not clear on your objectives, I am a little clearer now.

Yes I have read the information referenced.

"Do you think normal that computational time can be multiplied by factors between 2 and 20 for calculations that should be equivalent?" This question is maybe the crux of the matter and yes looking at it I do think this is normal.  You have taken an operation that is trivially small and encased it in some layers of complexity  and you are  then surprised the compiler produces code that takes much longer to run.  Perhaps if the underlying real work content was more significant the  factors are less? I haven't spent time studying in depth and it doubt I will, other priorities. So are the operations equivalent? No I don't think they are  because you are encapsulation the basic operation in many constraints and requirements.  My 100m run time will increase if I have to juggle plates whilst doing it. 

I agree that   it should be theoretically possible for a clever compiler to see through the layers camouflage and produce near equivalent code  to give the required result but it doesn't.  Clearly there as many things we might need in our code, accuracy, ease of maintenance, ease of adaption, speed , robustness etc etc. and the code we produce  can be different dependant on what is most important to us. 

I do think there is plenty of scope of Intel to make more optimisations in this area but I am also pretty sure they are fully aware of this. 

[ojacquet]

It's kind of you to discuss.

You answer only one point: nested type-bound procedures...

But not the other points which reveal problems in the compiler that we would not logically expect: pieces of program having better performances when they are run separately than when they are run in the same program, or performances of the pieces of program modified when they are run in a different order.

This leads me to think that there are perhaps obvious margins for progress for those who have the means to dig (this is outside my skills).

[JohnNichols]

There is probably only a small development team at Intel on the compiler, I would be surprised if it is more than 10 people, including the usual manager, one day AI will replace management.  

So it is allocation of resources, I cannot see that this type of problem would be high on any priority list considering the small user base at that level and the cost.  

Time and cost will control.  

[AlHill]

"one day AI will replace management"

Yeah, right.   And, one day, Bruce Springsteen will finally learn to play the guitar.

Doc (not an Intel employee or contractor)
[Maybe Windows 12 will be better]

[ojacquet]

Again, I note with regret that the responses point in the direction of not prioritizing performance issues. However, I believed that the essence of Fortran was to be dedicated to high-performance calculations. I deplore the fact that users themselves are the first to highlight this prioritization: they don't see that by neglecting performance to such an extent, they are sawing off the branch they are on. If you are not performant, you disappear.

For nearly 25 years, I have been developing a Monte Carlo code in the field of nuclear reactor physics and nuclear safety, written in Fortran, since its inception in the 1970s. Unfortunately, the decision was made to abandon Fortran and rewrite everything in C++.

So, my contribution may have been my last attempt to give Fortran a chance. Is it possible to escape a logic that seems inexorable? the disappearance of Fortran because of a vicious circle: not enough evolutions, fewer and fewer users, older and older users, too much conservatism, a certain disconnection from reality, less and less economic profitability and therefore less human resources devoted to developing high-standard and efficient compilers...