Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: Damien Doligez <damien.doligez@inria.fr>
To: caml-list@inria.fr
Subject: Re: [Caml-list] Accuracy of Gc.stat ()
Date: Fri, 21 Nov 2003 17:46:31 +0100	[thread overview]
Message-ID: <425DBD4C-1C42-11D8-8941-00039310CAE8@inria.fr> (raw)
In-Reply-To: <1970C334-1AB9-11D8-ADB3-000393DBC266@epfl.ch>

On Wednesday, November 19, 2003, at 06:52 PM, Daniel Bünzli wrote:

> Since my first attempt [1] didn't really get through, I try to 
> reformulate my post.

Sorry I didn't answer earlier, the traffic on caml-list is getting
quite heavy these days.

> 1) What is the accuracy of these results ?
>
> E.g. I read in the documentation of the Gc module that the field 
> minor_words is only an approximation in programs compiled to native 
> code.

Because of the way we trigger a minor collection in native code, the
counters will overestimate the number of words allocated by a few words
per minor GC.  Note that it is always an overestimation, and the error
is at most 256 words per collection.

>  Is it also true for the other fields ?

No.  The other fields are accurate.

>  Would the figure minor+major-promoted be accurate ?

No.  The error in minor will propagate.

>  How much can I trust the figures I get ?

You can repeat your experiment after changing the size of the
minor heap, that will give you a good idea of the error.  The
bigger the heap, the smaller the error, and it converges to
error=0 for an infinite heap.

> 2) When I start profiling should I prefer a Gc.compact to a 
> Gc.full_major ?

If you're only interested in minor+major-promoted, you don't even
need a Gc.full_major.  A Gc.compact would be if you are timing a
very allocation-intensive program, and even then I doubt it will
make much difference.

> 3) Is it possible to know at runtime whether we are running native 
> code or interpreted bytecode ?

Good question.  I don't know the answer.  Maybe you should file this
as a feature wish in the bug tracking system:
< http://caml.inria.fr/bin/caml-bugs >.

> Regarding time profiling, a binding in the Unix module to the 
> getrusage() function would definitvely be nice.

Another candidate for the bug tracking system.

-- Damien

-------------------
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-11-21 16:45 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-11-19 17:52 Daniel Bünzli
2003-11-21 16:46 ` Damien Doligez [this message]
2003-11-22  0:20 ` Kim Nguyen
2003-11-22 11:43   ` Richard Jones
2003-11-22 11:49     ` Richard Jones
2003-11-22 14:20       ` Self-detection of native code execution (Was Re: [Caml-list] Accuracy of Gc.stat ()) Daniel Bünzli
2003-11-22 14:28         ` Richard Jones
2003-11-22 14:28       ` [Caml-list] Accuracy of Gc.stat () Kim Nguyen
2003-11-22 14:31         ` Richard Jones

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=425DBD4C-1C42-11D8-8941-00039310CAE8@inria.fr \
    --to=damien.doligez@inria.fr \
    --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