[Patch, Fortran, OOP] PR 45290/45271: pointer initialization / vtab init

[Tobias Burnus]

  Toon Moene wrote:
> [OOP]
>
> It would be really, really interesting to know (even just a little) 
> about the (run-time) cost of these abstractions. I am surrounded by 
> people who make the wildest claims about this (e.g., C++ is faster 
> than Fortran)

I really hate claims of the kind language A is faster than B. My 
impression so far was that essentially the performance is roughly 
equivalent - there are some differences in semantics but they often do 
not matter that much. There are larger differences in how one expresses 
certain operations - and thus a language might make it easier to express 
a certain task or to allow for certain optimizations. An example for 
this are the whole array operations or that a variable in Fortran does 
not alias by default - or the nice string patterns of Perl. Some 
differences in semantics (e.g. parenthesis handling differences between 
C and Fortran) can be overruled by optimization flags. But at the end, 
why should the same task take longer in one language as in another? How 
one implements a task and how the compiler optimizes (including which 
optimizations one allows it to do) if far more important.

In terms of the language, I think Fortran is such defined that a lot of 
optimizations are possible - often such that the user does 
"automatically" the right steps. A possible exception are whole array 
constructs: the compiler might insert temporaries, which cause a major 
slow down compared with a DO solution, if it cannot determine that a 
temporary is not required.

> and some hard data about the cost of object oriented design towards 
> code that's so easily (well, OK, *sparse* arrays) expressed in Fortran 
> 77 would be very interesting.

Well, as long as the dynamic type is known at compile time, one does 
compile time resolution and is back to the speed of Fortran 90/95. In 
case one does not, e.g. if one uses CLASS, invoking a type-bound 
procedures means that one resolves the address of a procedure pointer in 
a vtable and calls then the target of the proc pointer. Thus, a pointer 
resolution is involved. The additional disadvantage of using this 
pointer is that one hampers optimizations such as inlining. Some 
operations - such as the generic resolution (including OPERATOR(...)) is 
done at compile time - thus only the specific call has to be resolved 
(cf. above).

Essentially, C++ works the same: If you invoke a "method" a lookup in 
the vtable is done and then the function is called.

Thus, I expect a similar performance of OOP Fortran and C++. And for the 
programs I have seen so far, I do not expect a measuable slowdown due to 
using OOP - though I am sure some users will manage to produce programs 
which successfully use every possibility for slowdown ;-)

It is not completely clear what do you want to test? Shall one write 
from scratch F77, F2003, C and C++ programs which are identical in 
semantics and check then the performance? And what does not then really 
test - the programming capabilities of the implementors, the 
optimization support of the used compilers? Or really the language itself?

Tobias