Subj : Re: OO compilers and efficiency
To   : comp.programming
From : Rob Thorpe
Date : Mon Jul 25 2005 04:27 am

Jon Harrop wrote:
> Rob Thorpe wrote:
> > Jon Harrop wrote:
> >> No. I believe many other language implementations (e.g. ocamlopt) work in
> >> the same way but are much faster than Java. I think Java's poor
> >> performance is due to Java implementations failing to optimise common OO
> >> patterns.
> >
> > Really?
> > The problems with Java are mostly semantic: everything is an object and
> > every object must be on the heap.  I'm fairly sure that those who write
> > JVMs have mastered the art of optimizing them under these limitations.
> >
> > Java is a very big business, probably many hundreds of programmers
> > spend their time optimizing JVMs.  OCaml on the other hand is written
> > by only a handful of people.  I expect that the coders of JVMs have
> > optimized into the ground the OO patterns they have found to be the
> > most common.
>
> That is exactly what I had also wrongly assumed until I actually tried
> it. :-)
>
> The poor performance of Java relative to OCaml just goes to show that having
> hundreds of compiler-writers in big business is not as good as having a
> single good language designer.
>
> > More likely the semantics and common usage patterns of OCaml make it
> > easier.
>
> Yes, languages like OCaml and SML are much better designed than languages
> like C++, Java, C# etc.
>
> >> > and of course it has the extra overhead of GC unlike C++ and C.
> >>
> >> GC is often faster than manual allocation and deallocation so it isn't
> >> really fair to call it an "overhead". Indeed, I'd call manual allocation
> >> and deallocation an overhead...
> >
> > It's certainly mental overhead.  I doubt that there would be hardly any
> > situations where a GC would outperform manual allocation though.
>
> I suspect there are many practically-important situations where GC
> outperforms manual allocation. This isn't surprising given the
> sophistication and information available to a GC and the lack of
> information about "free" available to the average programmer.
>
> The main reason is simply amortisation, which is becoming increasingly
> important as cache coherency dominates the time spent executing on-CPU
> instructions.
>
> Although GC is likely to be faster than manual allocation, this should be
> considered as secondary compared to improved reliability. Stability is
> always more important than performance...

I'll deal with both of your comments on memory allocation here:

Jon Harrop wrote:
> Rob Thorpe wrote:
> > Yes, that's true, but malloc and free are generally very efficient.
>
> No, either or both of malloc and free are expensive. Which is cheap is not
> usually known to the programmer (usually malloc is cheaper). It is this not
> knowing that leads to inefficient code with manual allocation and
> deallocation via malloc and free. If you want to optimise your code then
> you should malloc a big block of memory and write your own customised
> memory allocation and deallocation routines.
>
> This is why malloc/new and free/delete are replaced by much faster, custom
> "allocators" in the C++ STL.

I certainly wouldn't argue that there will be some situations where GC
is more efficient.  It's also true that there's for some memory
allocations a substantial amount of work in either malloc or free. It
is normally "free" that contains this work, this can be assumed with a
fairly good degree of confidence.  Malloc/free are also as you say, bad
at small objects, it's useful to do the customized mini-allocation that
you mention.

Despite this malloc/free are generally very efficient overall.  A GC
will allocate very quickly, but the process of recycling garbage is
complex.  In the non-generational case it must touch a very large
amount of memory, often bigger than the cache, which is slow.  In the
generational case it must happen often.  Even Hans Boehm is not bold
enough to say GC is faster than malloc.

But all of this proves nothing.  Some day I will measure the
difference, some day ...

.