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 PAA05097; Thu, 1 Jul 2004 15:59:18 +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 PAA05082 for ; Thu, 1 Jul 2004 15:59:17 +0200 (MET DST) Received: from smtp3.adl2.internode.on.net (smtp3.adl2.internode.on.net [203.16.214.203]) by concorde.inria.fr (8.12.10/8.12.10) with ESMTP id i61DxESH007281 for ; Thu, 1 Jul 2004 15:59:16 +0200 Received: from [192.168.1.200] (ppp215-144.lns1.syd2.internode.on.net [203.122.215.144]) by smtp3.adl2.internode.on.net (8.12.9/8.12.9) with ESMTP id i61Dx3HY040291; Thu, 1 Jul 2004 23:29:04 +0930 (CST) Subject: Re: [Caml-list] Q: automatic forgetting cache, module Weak, Gc control From: skaller Reply-To: skaller@users.sourceforge.net To: Jacques GARRIGUE Cc: kybic@fel.cvut.cz, caml-list@pauillac.inria.fr In-Reply-To: <20040701.174358.116814367.garrigue@kurims.kyoto-u.ac.jp> References: <20040701.174358.116814367.garrigue@kurims.kyoto-u.ac.jp> Content-Type: text/plain Message-Id: <1088690342.2582.122.camel@pelican.wigram> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 01 Jul 2004 23:59:02 +1000 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 40E418B2.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 sourceforge:01 2004:99 jacques:01 caching:01 disadvantage:01 cyclic:01 buffer:01 buffer:01 thread-safe:01 lexically:01 dynamically:01 seamlessly:01 9660:01 glebe:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Thu, 2004-07-01 at 18:43, Jacques GARRIGUE wrote: [caching results] A more labor intensive idea would be to manage the caches yourself. This has the advantage -- and disadvantage -- that you're totally in control. One idea -- just use a fixed sized cyclic buffer, keep usage stats, and manually tune the buffer sizes. Another more flexible and potentially expensive technique is to cache everything in a thread-safe manner, and run a separate 'reaper' thread to purge the most useless values. This has the advantage that the cache control is lexically isolated and so can be worked on independently. Obviously needing to use a thread-lock to put values in the cache will cost big time. The big plus here is that you can actually tune the reaping dynamically .. that is, whilst the program is actually running. If you really want to get fancy you could actually make a second thread that output usage stats on a socket, and collect them in some kind of crude dynamic graph you could watch, so as to understand the loading better. I'm NOT recommending this technique over using Weak/GC tuning, I think you should try that first since it integrates seamlessly with the actual memory management system. -- John Skaller, mailto:skaller@users.sf.net voice: 061-2-9660-0850, snail: PO BOX 401 Glebe NSW 2037 Australia Checkout the Felix programming language http://felix.sf.net ------------------- 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