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
next prev parent 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