Re: [Caml-list] The boon of static type checking

[skaller <skaller@users.sourceforge.net>]

On Mon, 2005-02-07 at 04:28, Jon wrote:
> On Feb 6 2005, Radu Grigore wrote:
> > On Fri, 4 Feb 2005 10:26:55 +0000, Jon Harrop <jon@jdh30.plus.com> wrote:
> > > The code to implement a simple tree is unwieldy in C++ (e.g. 1975 LOC
> > > in stl_tree.h and stl_map.h vs 198 LOC in map.ml).
> > 
> > The implementation in stl_tree is not a "simple" tree. The difference
> > in size is also because the STL implementation is more efficient.
> 
> This is a much smaller effect compared to the verbosity imposed by inherent 
> inefficiencies of the C++ language though.

Curious what you think those are. 

g++ seems to generate better
code than ocamlopt for similar simple problems
(see Alioth for quantitative evidence given silly
set of sample 'problems')

IMHO the single major inefficiency in C++ is also a source
of efficiency -- lack of a garbage collector.

OTOH Ocaml has a massive inefficiency C++ does not,
namely boxing, and ocaml tools currently do not 
seem to be very good at unboxing.

Ocaml tools do much better with tail calls than g++,
but I don't see that this is an intrinsic fault
in C++: the 'callee pops arguments' gets in the
way with separate compilation, but not
for inline functions.

Again, C++ provides inline functions which
provide a way Ocaml does not have so easily 
for optimising.

Felix is a C++ code generatore which provides many
of the features of C++ which are clumbsy to encode
such as sum types and closures, does tail call
optimisation, and also provides a garbage collector. 
It currently appears to outperform the ocaml bytecode interpreter,
whereas the x86 native code compiler ocamlopt generates
faster code on average.

It is hard to say that Felix code 'is faster than C++'
given it actually generates it.

So I'm quite interested in what inefficiencies C++ might
have compared to ocaml -- feel free to identify not only
'intrinsic' inefficiency of the languages, but also
problems in the compilation models, and difficulties
in generating good code that are not necessarily
intrinsic. (EG I would like to hear a comment
that tail-rec optimisation whilst not 'intrinsically impossible'
in C++ is hard to do, if that is your belief)

One further comment: Ocaml and C++ share a serious impediement
to efficiency -- eager evaluation. In fact lazy evaluation
can also be inefficient. Which is why Felix is moving
towards an 'unspecified evaluation' strategy.
In fact the optimiser already assumes purity/termination,
there's a way to enforce eagerness, but I have no way
to enforce laziness at the moment :(

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net