Subj : Re: OO compilers and efficiency To : comp.programming From : Jon Harrop Date : Sun Jul 24 2005 08:48 pm 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... -- Dr Jon D Harrop, Flying Frog Consultancy http://www.ffconsultancy.com .