This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: [Patch, Fortran, OOP] PR 45290/45271: pointer initialization / vtab init
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
- References:
- Re: [Patch, Fortran, OOP] PR 45290/45271: pointer initialization / vtab init
- From: Dominique Dhumieres
- Re: [Patch, Fortran, OOP] PR 45290/45271: pointer initialization / vtab init
- Re: [Patch, Fortran, OOP] PR 45290/45271: pointer initialization / vtab init
- Re: [Patch, Fortran, OOP] PR 45290/45271: pointer initialization / vtab init
- Re: [Patch, Fortran, OOP] PR 45290/45271: pointer initialization / vtab init