Performance of integers in floating point calculations and assignments

[Andrew_Smith]

Decorating constants with _8 or _DP where DP is an integer parameter makes code look odd and nothing like other languages so I would like to avoid it where the constant is an integer.

Similarly use of D exponent in place of E makes code harder to transfer to other languages that have other ways to infer the type of the constant.

Is there any performance difference between these two assignments? e.g.
real(8) a
a = 1
or
a = 1.0_DP

And how about mixed inside floating point equations?
real(a)
a = 24 * 6.876D0
or
a = 24_D0 * 6.876D0

I am hoping that the compiler will convert the integers to floating points of suitable type and the runtime performance and numerical result will be identical.

I know about the potential truncation issue if integers are divided so in that case use of decoration or explicit type conversion is always needed e.g.
a = 1/3_DP
or
a = 1/real(3, DP)

Which is the preferred decoration D0 or _DP ?

[FortranFan]

@Andrew_Smith ,

First, please note your inquiries in the original post are of general Fortran in nature.  As such, you may find it beneficial to engage with the broader community of Fortran practitioners who also read other online forums such as comp.lang.fortran but especially now the Fortran Discourse site at https://fortran-lang.discourse.group/.  The wider feedback you will receive from a diverse group of active Fortranners also at other sites such as Fortran Discourse may prove quite useful to you.

Now, on your inquiries here, my 2 cents' will be as follows:

1. You will absolutely struggle to notice any performance impact with modern compilers due to ordinary assignments of the kind `var = expr` where `var` is a floating-point object whereas `expr` is an integer-literal-constant.  What might prove more pertinent to you and the team(s) working with the codes in question is readability and maintenance and any potential for human errors arising from any misunderstanding due to the differences in type and kind in LHS vs RHS.
2.  Same with mixed-mode arithmetic in expressions (what you call equations) i.e., the use of constants and objects of different types in the same expression.  Note the Fortran standard has certain semantics that the processor(s) may or may follow depending on compiler options.  And this may differ from other programming languages.  It is rather difficult to keep things straight, particularly as more team members work on the code who may be you yourself in different points in time influenced differently by other circumstances.  Thus correctness, accuracy, and maintainability become paramount.  You will notice the conventional wisdom which is to avoid mixed-mode arithmetic.
3. In terms of the kind suffix introduced starting Fortran 90 standard revision, what you call "decoration", you will recall the general recommendation to work with defined kinds of types of interest e.g.,

   integer, parameter :: xx = selected_real_kind( p=.. )
   ! or ieee_selected_real_kind
   ! where xx is a suitable mnemonic e.g., RK or WP, etc.

   real(xx) :: a
   .
   a = 1.0_xx/3.0_xx  !(or 1/3.0_xx)

Separately, a suggestion will be to define named constants and use them consistently and exclusively in expressions rather than numerical literals (a ka magic numbers).

[JohnNichols]

The magic numbers in BASE.F90 developed by @mecej4 makes life really simple.  The biggest beef is some use WP and some use DP and it can be interesting to change to all DP.  

One can still make errors, but they are easier to find.  Anyone who has coded the Darcy Weisbach equation wants it to look just like the text books.   But someone should create a special symbol for 2g it is so common.