Subj : Re: OO compilers and efficiency
To   : comp.programming
From : Jon Harrop
Date : Wed Jul 20 2005 01:46 am

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.

>> 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.

[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.

[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.

> * OO languages typically [ie, Java] come with GC. C doesn't. 

OO programs will often be written in C++ and, consequently, often lack GC.

>   This can make an enormous difference to the simplicity of OO
>   code.

As GC has nothing to do with OO, this point is invalid. You can say, "GC
makes Java code simpler than C code".

>   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. 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.

>   (What the OO program loses in GC costs is roughly 
>   the same as what the C program loses in memory-management
>   costs, eg copying.)

Again, this point is invalid simply because there is no logical
correspondance between OO and GC.

> * 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.

>   The stronger 
>   semantics of OO languages (well, really, most not-C languages)
>   give them greater manoeuvering power in their optimisations.

Yes, languages can make certain classes of optimisation tractable.
Referential transparency is perhaps the simplest example.

However, OO is a poor example of something which allows the compiler to
perform signficantly more effective optimisations. For example, the common
constructs I mentioned earlier are obfuscated beyond recognition when
shoehorned into OO.

>> Or am I the only one who worries about this stuff?  Is it a
>> concern or should I kind of push it back into the recesses
>> of my mind and say the wastefulness is part of the tradeoff
>> for programming OO code?

If you want to write efficient, non-trivial code then you should start by
looking at the big picture (algorithms) and not details like bit twiddling
in C.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

.