Subj : Re: OO compilers and efficiency
To   : comp.programming
From : Jon Harrop
Date : Thu Jul 21 2005 12:17 am

Chris Dollin wrote:
> Jon Harrop wrote:
>>> There's unnecessary plumbing, I'll grant; are we talking more than a
>>> factor of 2 here? Ish?
>> 
>> I'd expect SML and OCaml to be up to 5x faster than Java.
> 
> Just for closures, or in general? Deep gloom. I thought they'd got
> the performance of Java up better than that.

For anything which does lots of allocation and deallocation. MLs are
typically extremely fast at allocation and deallocation. Not only is Java
very slow at object allocation and deallocation, it forces you to use
objects when there are often more appropriate and efficient constructs.

>>> 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.
>> 
>> As Java forces you to use OO,
> 
> Heap-allocated objects, to be specific, yes?

Yes. I'm not sure it's relevant though, e.g. the OCaml compiler happens to
heap allocate, the SML may be heap or stack, the C++ is mostly stack and
all are much faster than Java.

My guess is that C++ does a much better job of optimising simple objects
(e.g. structs) whereas Java (at least Sun's JDK 1.5) does a very poor job.

>> the Java implementation of my ray tracer
>> allocates and deallocates millions of unnecessary objects. In contrast,
>> the C++ object is nothing more than a struct and the SML and OCaml choose
>> to use a variant type. Consequently, the Java is up to 5x slower.
>> 
>> A masochist can rewrite the OCaml to use an object for each 3D vector.
>> The OCaml is then also very slow. But this is "unnatural" OCaml code.
> 
> Presumably the Java programmer can write equally unnatural code that
> avoids creating new objects ...

No. The Java code which avoids objects is much more unnatural because Java
tries to force you into (over)using OO. Specifically, avoiding objects in
Java requires you to write in C style.

In the other languages, there are simple alternatives (structs in C++,
records or tuples in MLs) which are just as natural (they cost nothing in
terms of clarity and verbosity) but which are substantially more efficient.

>> There is no elegant way around the performance bottleneck of objects in
>> Java.
>> 
>>>> 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 -
>> 
>> The C++ STL certainly contains a lot of code related to "closures".
> 
> Does that count as "common"?

Some uses of closures are so common in imperative programming that they have
a name - "callbacks".

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
Technical Presentation Software
http://www.ffconsultancy.com/products/presenta

.