Subj : Re: OO compilers and efficiency
To   : comp.programming
From : Rob Thorpe
Date : Wed Jul 20 2005 11:21 am

Jon Harrop wrote:
> Chris Dollin wrote:
> > Brian wrote:
> >> OO seems like it must be very wasteful.
> >
> > Does it?
>
> Yes. The OO implementations of many useful constructs (e.g. closures and
> variant types) are certainly many times more verbose and, I suspect, it
> will be difficult for a compiler to do a good job of spotting when the OO
> is actually implementing something quite simple.
>
> For example, I'd bet than languages with built-in support for closures, e.g.
> SML and OCaml, handle them vastly more efficiently than only-OO languages,
> e.g. C++ and Java.

The speed of implementation of lexical closures depends on the
languages concept of namespace.  If namespace are a simple concept it
can be done fast.  The closure can become a pointer to a namespace and
a pointer to a function.

In ML and lisp namespaces are tied to "let" rather than to subroutines,
which helps.  In this case "let" deals with hoovering up variables and
putting them in a namespace.

I don't know how closures are constructed in C++ or Java, but there's
nothing major preventing them from being efficient.

> >> Are compilers generally smart enough to inline the two calls into
> >> one?
> >
> > Pass - but were I writing a compiler (better, a JIT)
>
> From a performance point of view, the evidence seems to suggest "probably
> better _not_ a JIT" as Java is rarely as fast as C++ and is often several
> times slower.

This is getting rather off-topic, but anyway ...
I think it's difficult to say if JIT is an intrinsically poorer
approach from a performance point of view than direct compiling.  The
problem is that the only languages that have had seriously optimized
JITs created for them are Java and MS CLR.  These have semantic
problems and library problems that often cause them to be inefficient
anyway.  Other higher-level languages may do better, but at present who
knows?

> [get and set]
> > It can't (in general) be a register read; instance variables aren't
> > (cannot-ish) be stored in registers, they're a slot in the instance
> > object.
>
> The data can be cached in a register.

But why would you?  If we're talking about get and set methods then
they're getting or setting something outside the scope of the function
they are called from.  To cache such a value in a register in that
function the code would have to first load it into that register
somewhere in the function, then it could be set.  After this, before
exiting the function it must be copied back to memory.  So, there's
likely to be more cost than benefit.

> [cost of OO]
> > So the cost is small, even if the getter isn't inlined.
> >
> > This is no different from compiling non-OO code, of course.
>
> Not if you're using OO because the language forces you to, when another
> construct would be more appropriate. This is very common, IMHO.

Definitely agree.

> >   That means that OO programs can tackle larger problems
> >   with the same-ish amount of engineering effort  - they can
> >   out-produce the C programmer before the code efficiency is
> >   an issue.
>
> Yes, C++ is more expressive than C. This leads to more succinct, robust and
> often faster programs.

But at the cost of a great deal of complexity in the programmer.  I
have only met one person who I suspect actually knows C++.  Every other
programmer I've met knows only some parts of it and is at sea in
others, or just ignores them.
This renders communication -which is very important- more difficult.

I doubt C++ leads to faster programs than C.

> Many other languages gain this ability without need
> of OO (e.g. SML) and some combine many features (e.g. OCaml). Despite the
> theoretical space saving of OO, Java is one of the most verbose languages.

Also, MLs don't require quite the encylopedic knowledge C++ does.

> > * The writers of OO compilers are not stupid and will make
> >   every effort to generate not-stupid code.
>
> If OO makes it impossible to perform optimisations in the general case then
> the intelligence of the OO compiler writer's is unimportant - OO will
> necessarily lead to slower code in general.
>
> This certainly appears to be the case with Java, where object-intensive code
> is several times slower than the equivalent C++/SML/OCaml. For example,
> when dealing with 3D vectors. The solution is to code your Java as you
> would code in C, which takes you right back to square one.

I think that's as much caused by Java's implementation of
object-orientation than because of the concept itself.  But I agree, OO
doesn't allow much new potential for speedup, and causes performance
problems of it's own.

.