On Sun, 7 Dec 2003, Nuutti Kotivuori wrote:

> Well sure, that will help and is a good idea in general. But it will
> never allow for inlining of the function body into the calling
> function, and as such will never solve the underlying problem.

I actually question the value of inlining as a performance improvement, 
unless it leads to other signifigant optimizations.  Function calls simply 
aren't that expensive anymore, on today's OOO super-scalar 
speculative-execution CPUs.  A direct call, i.e. one not through a 
function pointer, I benchmarked out at about 1.5 clocks on an AMD K6-3.  
Probably less on a more advanced CPU.  Indirect calls, i.e. through a 
function pointer, are slower only due to the load to use penalty.  If the 
pointer is in L1 cache, an indirect call is probably only 3-8 clocks.

Cache misses are the big cost.  Hitting L1 cache, the cheapest memory 
access, is generally 2-4 clocks.  L2 cache is generally 6-30 clocks.  
Missing cache entirely and having to go to main memory is 100-300+ clocks.  
Inlining expands the code size, and thus means you're likely having more 
expensive cache misses.  At 300 clocks/cache miss, it doesn't take all 
that many cache misses to totally overwhealm the small advantages gained 
by inlining functions.

-- 
"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
                                - Gene Spafford 
Brian

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners