From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id 0D492BC57 for ; Sun, 28 Nov 2010 14:26:25 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtIBADfn8UxKfVIukGdsb2JhbACDUJEHhl+HSwgVAQEBAQkJDAcRAx+neYkoPIIYg3suiFYBAQMFhE9zBIFcjHuCCg X-IronPort-AV: E=Sophos;i="4.59,270,1288566000"; d="asc'?scan'208,217";a="89511167" Received: from mail-ww0-f46.google.com ([74.125.82.46]) by mail1-smtp-roc.national.inria.fr with ESMTP; 28 Nov 2010 14:26:24 +0100 Received: by wwb28 with SMTP id 28so2864889wwb.3 for ; Sun, 28 Nov 2010 05:26:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=EVWYP2dm4Gop7ikA5SVVKWMoIxsIfnCyWg350RgwAXM=; b=Yo5jZmCWLszs1ocaJ1BAEdoxPQ9O6pNtmauAiddzuU9DpJ0axhgSFpubOnZT090rxe TLSChsyJqvF2i8xgl0PGV/xp19cHeUgUWtzI7Zwn+64nzP/SxDHyhmcmGzgF7daxEyIW U8m4z3FCPwzR5rXld9MmZUmVvJwDHmZ25GuRw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type; b=pKAMX871H+aNT+anXFsJgw1LmbDEq0S+xJ4ra2dZwQqVYTP3zFvzgyaoui8K7oIMN0 oXfn91z5Ad0ejQ1TtKEfcC7AfNFHPzaui+FkgwfdoquqpSodoAj2+HQa6j93FhdGDZHj zNjNqzr1UffzhlAqMFKEyUIJ+3L47wlYnler0= Received: by 10.227.127.79 with SMTP id f15mr4632677wbs.86.1290950782388; Sun, 28 Nov 2010 05:26:22 -0800 (PST) Received: from macbookpro.local (bin73-1-78-240-16-62.fbx.proxad.net [78.240.16.62]) by mx.google.com with ESMTPS id f35sm120117wbf.14.2010.11.28.05.26.20 (version=SSLv3 cipher=RC4-MD5); Sun, 28 Nov 2010 05:26:21 -0800 (PST) Message-ID: <4CF25878.4060202@univ-savoie.fr> Date: Sun, 28 Nov 2010 14:26:16 +0100 From: Christophe Raffalli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; fr; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: caml-list@yquem.inria.fr Subject: OCaml GC [was Is OCaml fast?] References: <1290434674.16005.354.camel@thinkpad> <582306206.731582.1290438133628.JavaMail.root@zmbs4.inria.fr> <20101122203334.7adc5ee6@deb0> <20101127221121.0920db65@ordinaves.concept-micro.com> In-Reply-To: <20101127221121.0920db65@ordinaves.concept-micro.com> X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA7C257AF12E0A68770A1CB99" X-Spam: no; 0.00; christophe:01 raffalli:01 ocaml:01 ocaml:01 0200,:01 compaction:01 gced:01 syntax:01 node:01 syntax:01 cheers:01 christophe:01 beginner's:01 bug:01 0200,:01 X-Attachments: cset="UTF-8" cset="UTF-8" type="application/pgp-signature" name="signature.asc" name="signature.asc" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA7C257AF12E0A68770A1CB99 Content-Type: multipart/alternative; boundary="------------050206050804050002070602" This is a multi-part message in MIME format. --------------050206050804050002070602 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Le 27/11/10 22:11, Pierre Etchema=C3=AFt=C3=A9 a =C3=A9crit : > Le Mon, 22 Nov 2010 20:33:34 +0200, T=C3=B6r=C3=B6k Edwin a =C3=A9crit : > >> Not sure what the max should be for the minor heap increase, but based= >> on this benchmark increasing size of minor heap never slows down the >> program. Even when size of minor heap exceeds what fits in the cache. >> I guess there is another microbenchmark that can show the opposite >> though. > Another consequence of increasing minor heap size is the latency > introduced by minor heap collections. That said, when does it become > the worse garbage collector latency? (... when heap compaction is > disabled?) > And of course, for many programs such latency matters a lot less than > thoughput... In fact, an allocated block is visited at most twice by a minor GC and if promoted (that if visited twice by the minor GC) at least once by the major GC (when freed because major GC is mark and sweep) ... So a heap allocated block is traversed 0, 1, 3 or more time by one of the GC ... So increasing the minor heap size strictly decreases the number of time a word is examined by one of the GC ... I think that having two heaps is mainly (only ?) for one reason: collecting some memory sooner (and therefore using less memory for dead objects). This may speed up the program because saving memory decreases cache misses, but normaly it slows down the program. But it is still better than one generation GCed more frequently = =2E.. The latency is not directly related to minor collection ... If there was only the major heap, OCaml could still to a bit of major-gc cycle at each collection ... This is a (good) design choice of OCaml to have a small minor heap that can be collected in a short time by a simple and fast "stop and copy" algorithm. The main problem of the bin-tree benchmark is when you know that an object will live long enough to be promoted, you can not ask OCaml to allocate it in the major heap directly. This is why increasing the minor heap to have all object collected at the first GC works. A syntax like Node#(x,d,y) to allocate a variant in the major heap directly together with similar syntax for tuples, records, ... could be quite useful in OCaml in general for known long living objects ... An the is the Ancient modules for object that will live even longer. Cheers, Christophe > > _______________________________________________ > Caml-list mailing list. Subscription management: > http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list > Archives: http://caml.inria.fr > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs --------------050206050804050002070602 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Le 27/11/10 22:11, Pierre Etchema=C3=AFt=C3=A9 a =C3=A9crit=C2=A0: 
Le Mon, 22 Nov 2010 20:33:34 +0200, T=C3=B6r=C3=B6k =
Edwin <edwintorok@gmail.com> a =C3=A9crit :


Not sure what the max should be for the minor heap=
 increase, but based
on this benchmark increasing size of minor heap never slows down the
program. Even when size of minor heap exceeds what fits in the cache.
I guess there is another microbenchmark that can show the opposite
though.

Another consequence of increasing minor heap size is the latency
introduced by minor heap collections. That said, when does it become
the worse garbage collector latency? (... when heap compaction is
disabled?)
And of course, for many programs such latency matters a lot less than
thoughput...
In fact, an allocated block is visited at most twice by a minor GC and
if promoted (that if visited twice by the minor GC) at least once by the major GC (when freed because
major GC is mark and sweep) ... So a heap allocated block is traversed 0, 1, 3 or more time by one of the GC ...

So increasing the minor heap size strictly decreases the number of time a word is examined by one of the GC ...

I think that having two heaps is mainly (only ?) for one reason:
collecting some memory sooner (and therefore using less memory for dead objects).
This may speed up the program because saving memory decreases cache misses, but normaly it slows down the
program. But it is still better than one generation GCed more frequently ...

The latency is not directly related to minor collection ... If there was only the major heap,
OCaml could still to a bit of major-gc cycle at each collection ... This is a (good) design choice of OCaml
to have a small minor heap that can be collected in a short time by a simple and fast "stop and copy"
algorithm.

The main problem of the bin-tree benchmark is when you know that an object will live long enough to be promoted, you can not ask OCaml to allocate it in the major heap directly. This is why increasing the minor heap to have all object collected at the first GC works.
A syntax like Node#(x,d,y) to allocate a variant in the major heap directly together with similar syntax for
tuples, records, ... could be quite useful in OCaml in general for known long living objects ... An the is the Ancient modules for object that will live even longer.

Cheers,
Christophe






_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinf=
o/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_b=
eginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

--------------050206050804050002070602-- --------------enigA7C257AF12E0A68770A1CB99 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzyWHsACgkQi9jr/RgYAS6IzQCcDMH4/grrcgM+oJvYggJVj38t PXwAoIao4LwYAHfNEWHLyKKLLX3uNSND =gNpU -----END PGP SIGNATURE----- --------------enigA7C257AF12E0A68770A1CB99--