Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: Jerome Vouillon <Jerome.Vouillon@inria.fr>
To: chet@watson.ibm.com, Jerome Vouillon <Jerome.Vouillon@inria.fr>
Cc: caml-list@inria.fr, blo.b@infonie.fr
Subject: Re: Efficency in OCaml
Date: Thu, 2 Sep 1999 01:09:39 +0200	[thread overview]
Message-ID: <19990902010939.12962@pauillac.inria.fr> (raw)
In-Reply-To: <199909011840.OAA01846@bismarck.chet.org>; from chet@watson.ibm.com on Wed, Sep 01, 1999 at 02:40:21PM -0400

On Wed, Sep 01, 1999 at 02:40:21PM -0400, chet@watson.ibm.com wrote:
> Is there a description of the Ocaml object and
> "virtual-function-table" format?

I have not written any description but I can explain it rapidly here.
Objective Caml uses a scheme which is also used in the Gnu Objective C
compiler.

Each object holds a table containing its methods (the table is shared
among all objets of a same class). A unique integer is assigned at
run-time to each method name of a program.  This integer is used as an
index in this table to find the method. As the table is rather sparse,
it is implemented as a two-level array (an array of arrays of
functions). So, a method call
  "object#m e1 ... en"
is compile in something that looks like
  "object.(0).(idx mod N).(idx / N) objet e1 ... en"
where idx is the integer associated to the method name "m".

This scheme is very flexible and rather efficient. It would be hard to
improve it actually. Indeed, one will always need one indirection to
know what class the object belongs to and another indirection to
retrieve the method. So one could only gain one indirection (the
arithmetics is more or less free, as it can be done in parallel).
Actually, there is yet another indirection, not shown here, to
retrieve a pointer to the code from the method closure. This
indirection could probably be optimize a bit (by doing it in parallel
with the retrieval of the closure).

A great part of the cost of a method call also comes from the fact
that calling an unknown function is more expansive than calling a know
function : there is a check to see if the function is called with less
arguments than it needs, more arguments or exactly the right number of
arguments. The only way to optimize this would be to make a global
analyze of the program during the compilation. This analyze would
determine whether at a given method invocation location "x#m" all
methods that could possibly be called are called with the right number
of arguments, and would also check whether the method invocation could
be replaced by a function call (that is, whether only one method can
be called from this location). In order to provide more opportunities
for optimization, one would also probably need to do some partial
evaluation. Implementing all this would require a lot of work...

> Also, well, I think there's been some recent work on analyzing the
> path-length of O-O code, and the conclusion has been that in fact,
> methods do just "call one other" a lot.
> 
> That is, while C code is characterized by lots of tests and longer
> path-lengths per function-body, C++ (and Java, *especially* -- geez,
> it seems like Java code is all method-calls!) code tends to be short
> code-bodies, with branches implemented effectively by calling virtual
> functions.

OCaml is first a functional langage so I think (I hope) that people do
not use objects as heavily as in Java, and for instance use pattern
matching rather than only method calls for implementing branches.

-- Jérôme




  reply	other threads:[~1999-09-02 18:45 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <7qj9lv$aa9$1@goldenapple.srv.cs.cmu.edu>
1999-09-01 18:40 ` chet
1999-09-01 23:09   ` Jerome Vouillon [this message]
1999-09-04 14:26     ` Nicolas Ollinger
1999-09-10 13:14       ` Jerome Vouillon
1999-09-10 15:19     ` Hendrik Tews
1999-09-10 19:03       ` chet
1999-09-15 12:39       ` Jerome Vouillon

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=19990902010939.12962@pauillac.inria.fr \
    --to=jerome.vouillon@inria.fr \
    --cc=blo.b@infonie.fr \
    --cc=caml-list@inria.fr \
    --cc=chet@watson.ibm.com \
    /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