From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id RAA14384; Fri, 13 Aug 2004 17:44:29 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id RAA19439 for ; Fri, 13 Aug 2004 17:44:27 +0200 (MET DST) Received: from smtp.cegetel.net (mf01.sitadelle.com [212.94.174.78]) by concorde.inria.fr (8.12.10/8.12.10) with ESMTP id i7DFiQRM011641 for ; Fri, 13 Aug 2004 17:44:27 +0200 Received: from univ-savoie.fr (unknown [80.125.77.158]) by smtp.cegetel.net (Postfix) with ESMTP id 193D63796E; Fri, 13 Aug 2004 17:44:23 +0200 (CEST) Message-ID: <411CE1D1.8070304@univ-savoie.fr> Date: Fri, 13 Aug 2004 17:44:17 +0200 From: Christophe Raffalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040115 X-Accept-Language: en-us, en MIME-Version: 1.0 To: skaller@users.sourceforge.net Cc: Jacques Garrigue , Christoph.Bauer@lms-gmbh.de, caml-list Subject: Re: AW: [Caml-list] The tag bit References: <20040813.125329.74721093.garrigue@kurims.kyoto-u.ac.jp> <411CBAF6.3010101@univ-savoie.fr> <1092407293.29139.219.camel@pelican.wigram> In-Reply-To: <1092407293.29139.219.camel@pelican.wigram> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Miltered: at concorde with ID 411CE1DA.002 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; raffalli:01 raffalli:01 univ-savoie:01 caml-list:01 2004:99 encodings:01 generational:01 savoie:01 chablais:01 73376:01 univ-savoie:01 lama:01 enigmail:01 mutt:01 christophe:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk skaller wrote: > On Fri, 2004-08-13 at 22:58, Christophe Raffalli wrote: > > >>Does anyone have a comparison between two identical GC except one >>should have a tag bit and the other be conservative ? > > > The Boehm collector is quite efficient: if you compare it > to hand written encodings such as reference counting > for example. > > The main problem with it is that it has to 'stop the world' > whilst it is doing its thing, and so isn't useful for > real time applications such as a game where you can easily > pay 20% of all CPU for the GC -- but you simply can't freeze > up the game for 10 seconds every few minutes. > > The Ocaml generational collector is likely to be much better > at this -- some of the workload is spread over time, and > the remaining major collection when needed will also be > faster, and can be called manually at appropriate points. > > A second point is -- Boehm cannot defragment memory. > Ocaml can (although the compaction is 'world stop'). > > So .. i don't think the 'overall CPU use' of the two collector > kinds is actually what you need to compare: the real time > performance and/or ability to operate with C/C++ code > are the likely issues. > > It is not true, on some configuration (including intel I think) Boehm's GC can be incremental. At least the documentation say so. -- Christophe Raffalli Université de Savoie Batiment Le Chablais, bureau 21 73376 Le Bourget-du-Lac Cedex tél: (33) 4 79 75 81 03 fax: (33) 4 79 75 87 42 mail: Christophe.Raffalli@univ-savoie.fr www: http://www.lama.univ-savoie.fr/~RAFFALLI --------------------------------------------- IMPORTANT: this mail is signed using PGP/MIME At least Enigmail/Mozilla, mutt or evolution can check this signature --------------------------------------------- ------------------- 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