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 QAA26810; Tue, 18 Sep 2001 16:22:38 +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 QAA26795 for ; Tue, 18 Sep 2001 16:22:36 +0200 (MET DST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id f8IEMVr15307; Tue, 18 Sep 2001 16:22:31 +0200 (MET DST) Received: (from xleroy@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id QAA27010; Tue, 18 Sep 2001 16:22:30 +0200 (MET DST) Date: Tue, 18 Sep 2001 16:22:30 +0200 From: Xavier Leroy To: Marco Maggesi Cc: caml-list@inria.fr Subject: Re: [Caml-list] mark_slice, sweep_slice, oldify Message-ID: <20010918162230.H23689@pauillac.inria.fr> References: <877kv04y6e.fsf@sisiphos.math.unifi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <877kv04y6e.fsf@sisiphos.math.unifi.it>; from maggesi@math.unifi.it on Sat, Sep 15, 2001 at 11:10:17AM +0200 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > With the aid of gprof I noticed that my program spends most of the time > of the computation in three functions `mark_slice', `sweep_slice' and > `oldify' (see below the output of gprof obtained after the computation > of some products of polynomials). > > What does this exactly mean? This is the generational garbage > collector, right? Yes. "oldify" is the minor copying collector, and "mark_slice" and "sweep_slice" are the incremental mark-and-sweep major collector. > May I low the cost of GC? There is no general answer to this question. As a rule of thumb, allocating small, short-lived blocks (that die before the next minor collection) is very cheap; longer-lived objects cost significantly more. You could try to play with the GC settings (either at start-up via the CAMLRUNPARAM environment variable, or programmatically via the Gc.get and Gc.set functions). E.g. if many of your blocks survive a minor collection but die shortly thereafter, increasing the size of the minor heap could help. If your program runs for a short amount of time, you could try increasing the "overhead" parameter to, say, 100, to make the incremental major collector work less. The GC statistics returned by Gc.stat could also be of interest, although you need a bit of background in garbage collection to understand what they really mean :-) Sometimes, the program can be rewritten to eliminate allocation of intermediate data structures. This is known as "deforestation" in the literature. For a simple-minded example: if you often sum three polynomials, instead of writing "poly_add x (poly_add y z)" (which causes the intermediate polynomial y + z to be allocated), write a "poly_add3" function that will sum three polynomials in one go. Good luck, - Xavier Leroy ------------------- Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr