caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Abdulaziz Ghuloum <aghuloum@cs.indiana.edu>
To: caml-list@inria.fr
Subject: Re: [Caml-list] Object-oriented access bottleneck
Date: Sun, 07 Dec 2003 18:50:10 -0500	[thread overview]
Message-ID: <3FD3BCB2.3090506@cs.indiana.edu> (raw)
In-Reply-To: <Pine.LNX.4.44.0312071318110.5009-100000@localhost.localdomain>

Brian Hurt wrote:

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

Hello,

Do you happen to have a pointer to a document listing the (approximate) 
timing of the various instructions on todays hardware?  You have listed 
a few and I was wondering if you have a more comprehensive study.

You say "Inlining expands the code size and thus you're likely having 
more expensive cache misses".  I wonder how true that is.  For example, 
consider a simple expression such as {if p() e0 e1}.  If the compiler 
decides to inline p (in case p is small enough, leaf node, etc ...), 
then in addition to the benefits of inlining (no need to save your live 
variable, or restore them later, constant folding, copy propagation, 
...), you're also avoiding the jump to p.  Since p can be anywhere in 
memory, a cache miss is very probable.  If p was inlined, its location 
is now close and is less likely to cause a cache miss.  Not inlining 
causes the PC to be all over the place cauing more cache misses.  Am I 
missing something?

Aziz,,,


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


  reply	other threads:[~2003-12-07 23:50 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-12-07  2:39 Nuutti Kotivuori
2003-12-07  2:59 ` Nicolas Cannasse
2003-12-07 11:22   ` Benjamin Geer
2003-12-07 14:12     ` Nicolas Cannasse
2003-12-07 18:04   ` Nuutti Kotivuori
2003-12-07 10:27 ` Jacques Garrigue
2003-12-07 19:46   ` Nuutti Kotivuori
2003-12-08  1:07     ` Jacques Garrigue
2003-12-08 15:08       ` Nuutti Kotivuori
2003-12-08 15:42         ` Richard Jones
2003-12-09  0:26           ` Nicolas Cannasse
2003-12-09 12:10             ` Nuutti Kotivuori
2003-12-09 13:17               ` Olivier Andrieu
2003-12-09 13:53                 ` Nuutti Kotivuori
2003-12-08 17:51       ` Brian Hurt
2003-12-08 18:19         ` brogoff
2003-12-08 20:09           ` Brian Hurt
2003-12-08 19:02         ` Xavier Leroy
2003-12-08 21:37           ` Brian Hurt
2003-12-08 21:06             ` Nuutti Kotivuori
2003-12-08 22:30             ` malc
2003-12-07 18:23 ` Brian Hurt
2003-12-07 18:14   ` Nuutti Kotivuori
2003-12-07 19:30     ` Brian Hurt
2003-12-07 23:50       ` Abdulaziz Ghuloum [this message]
2003-12-08 17:29         ` Brian Hurt
2003-12-08 18:48           ` Nuutti Kotivuori
2003-12-08 10:17       ` Nuutti Kotivuori
2003-12-08 19:51       ` skaller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3FD3BCB2.3090506@cs.indiana.edu \
    --to=aghuloum@cs.indiana.edu \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).