On Sun, 6 Feb 2005 23:34:02 -0600 (CST), Brian Hurt <bhurt@spnz.org> wrote:
> Probably a bad idea, but I've got to jump in here.
> 
> Full disclosure: I *hate* C++.  Mainly because I've actually written real
> programs in it.  The next time I have to use C++ in any sort of serious
> way I'm registering c++sucks.com and starting a website to catalog all the
> different ways C++ sucks.  Feel free to stop reading at this point.
:-)

> ...
> > g++ seems to generate better
> > code than ocamlopt for similar simple problems
> > (see Alioth for quantitative evidence given silly
> > set of sample 'problems')
> 
> Yep.  And, conservatively, 10 times as much effort has gone into the gcc
> optimizer as the Ocaml optimizer.  Possibly 100 times.  For, according to
> Alioth, about a 10% improvement.  It's only with gcc 3.x that C++ managed
> to beat Ocaml on performance.
More effort having gone into gcc and better performance of gcc are
arguments pro gcc, right? ;-)

> > IMHO the single major inefficiency in C++ is also a source
> > of efficiency -- lack of a garbage collector.
> 
> It's a source of efficiency on the small scale- it's easy to write a 1,000
> line program with hand allocation.  Rather harder to write a 10,000 line
> program, and a major bitch to write a 100,000 line program without garbage
> collection.
Personally I like it that in C++ you actually have the choice to use
appropriate garbage collection schemes when you desire to do (yep,
multiple kind of GCs for different subsystems/data/... is a win).
Makes it easier with > 1,000,000 line programs :-)

> > OTOH Ocaml has a massive inefficiency C++ does not,
> > namely boxing, and ocaml tools currently do not
> > seem to be very good at unboxing.
> 
> This is also a big efficiency for Ocaml, for two reasons.  First, it
> encourages code reuse.  Second, Ocaml only needs one implementation of a
> function for all types.  C++'s template system, to unbox everything,
> duplicates code like crazy- generally, a new implementation for every
> type.
Very true. Technically this would not be very difficult in C++,
though. There's a certain trade off you have to make for either way.

> > Again, C++ provides inline functions which
> > provide a way Ocaml does not have so easily
> > for optimising.
> 
> Don't assume that inlining is optimization.  Actually, it generally isn't.
> Having actually timed it on modern hardware, a function call costs like
> 2-3 clock cycles these days.  Plus 1-2 clock cycles per argument.  This is
> compared to the 10-30 clock cycles a mispredicted branch costs, the 20+
> clock cycles an L1 cache miss/L2 cache hit costs, and the 100-350+ clock
> cycles of an L2 cache miss/memory fetch.
Inlining for very small functions generally is an optimization.

> What little inlining is a good idea can be done by the compiler,
Yep, usually the "inline when appropriate" compiler switch + something
like__forceinline for very small functions (for paranoia reasons)
seems to be the way to go in my experience.

Michael