Subj : Re: OO compilers and efficiency To : comp.programming From : Chris Dollin Date : Wed Jul 20 2005 02:40 pm 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. .