Re: OO compilers and efficiency

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.

I believe the OP was rather coming from the other direction, ie from
"simpler" languages, or at least simpler idioms. I agree that (eg) Java
makes a right pigs ear of closure-like objects, but that isn't because
it's OO, it's because it's Java. Making methods first-class values
(including adding lexical closures) and adding lambda-abstractions
(or "blocks") doesn't appear to me to conflict with the OO style.

[I happen to think subclassing is nicer than "variant types", but
I may be thinking of the wrong notion fo "variant type" - old echoes
from Pascal, rather than notions like existential types etc; which
did you mean?]

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

I'm not convinced about `vastly`. EG one representation of a closure
is as a freshly-allocated chunk of memory with references to the
closed-over variables and a pointer to the underlying function; this
chunk is typed as a function.

If you immitate a closure in Java, you use a freshly-allocated object
with references to the closed-over variables and is of a class which
has an agreed method to call to run the underlying function.

There's unnecessary plumbing, I'll grant; are we talking more than a
factor of 2 here? Ish?

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

Pass on the evidence - but I'd write a JIT rather than a compiler, if
I could, because I'd have access to more information.

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

Hence "in general" and "-ish". (Remember that another thread may
change the value fo an instance variable between two reads in the#
original thread.)

>> * OO languages typically [ie, Java] come with GC. C doesn't.
>
> OO programs will often be written in C++ and, consequently, often lack GC.

I don't count C++ as an OO language; I count it as a multi-paradigm
language that, as a consequence, suffers in each of its paradigms from
the presence of the others. (And benefits, but in different places.)

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

OK, if you like.

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

I haven't written enough C++ to comment.

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

(Source code or compiled code size? Your use of "verbose" ambiguated
me.)

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

I don't believe this to be true; you may take this just as one of
my religious beliefs - if you don't have GC-style storage management,
you don't have OO. You may have /pieces/ of OO, of course.

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

The premise is unloaded, and the conclusion in any case uncertain.
["Not implemented" doesn't imply "impossible"; it may just be "not
in our preferred domain"; and worse general-case optimisation may
be trumped by algorithmic improvements made possible by the OO
structuring. No, I don't have any numbers either.]

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

For what values of "equivalent" in the first sentence? I don't doubt
that if you make lots of new objects you will do worse than if you
don't have to create them.

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

Yummy. Functional yummy.

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

I think "common" is pushing it rather - you seem to be conflating
the issue of whether OO program(s/ing) is "wasteful", to use the
OPs words -- by which I took him to mean wasteful *when idiomatic* --
with whether other, less idiomatic constructs, could be compiled
efficiently (or written efficiently) when in an OO language.

[Just for the record, I think highly of closures and higher-order
functions, have used and implemented languages which contain both,
and miss them sorely in Java.]

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

It's nice to end on a note of agreement.

--
Chris "electric hedgehog" Dollin
It's called *extreme* programming, not *stupid* programming.
.

Relevant Pages

  • Re: OO compilers and efficiency
    ... > will be difficult for a compiler to do a good job of spotting when the OO ... > For example, I'd bet than languages with built-in support for closures, e.g. ... I don't know how closures are constructed in C++ or Java, ... > The data can be cached in a register. ...
    (comp.programming)
  • Re: OO compilers and efficiency
    ... will be difficult for a compiler to do a good job of spotting when the OO ... For example, I'd bet than languages with built-in support for closures, e.g. ... makes Java code simpler than C code". ... If OO makes it impossible to perform optimisations in the general case then ...
    (comp.programming)
  • Re: The trend is to move away from Delphi...
    ... Perhaps you agree that C++ can be easier ported to another OS than other main stream>> native << languages. ... IIRC it simply passes C-Code to the underlying compiler. ... Delphi users stick to their fast "F9" behaviour pretty hard. ... Is there a full blown delphi compiler that runs on Java then? ...
    (borland.public.delphi.non-technical)
  • Re: a better procedural representation
    ... SICP environment a metaphor for activation records? ... for mainstream languages, including Pascal and other ... implement the first-class closures of Scheme-like ... recommend Appel's "Modern Compiler Implementation ...
    (comp.lang.scheme)
  • Re: Database applications in Linux
    ... > started with Smalltalk and Self, which is very different than languages ... > that compile source code into harware specific object code. ... What "Java Party?" ... You do it via running a compiler: ...
    (comp.os.linux.development.apps)