Version française
Home     About     Download     Resources     Contact us    
Browse thread
Estimating the size of the ocaml community
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Igor Pechtchanski <pechtcha@c...>
Subject: Re: [Caml-list] The boon of static type checking
On Mon, 7 Feb 2005, Michael Walter wrote:

> 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.
> :-)

As someone who has background in compiler optimizations (of Java, not C++,
but they are similar enough in the areas below), I'd like to address one
of Brian's points.

> > > 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.

FWIW, I agree with Brian that inlining in itself is most often not an
optimization at all.  However, the main power of inlining is that it
enables the compiler to apply intraprocedural optimizations globally.
Consider a huge complex dispatch function that, when inlined, boils down
to one method call (due to, e.g., constant propagation).  Most modern
compilers also do specialization if code bloat due to inlining is an issue
(I don't know off-hand if g++ does).
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"The Sun will pass between the Earth and the Moon tonight for a total
Lunar eclipse..." -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT