From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id pB88usQ9012785 for ; Thu, 8 Dec 2011 09:56:54 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEGAJZ64E7RVdK2kWdsb2JhbABAA5o3NIdkAYZ0gRgIIgEBAQEJCQ0HEieBcgEBAQECARICLAEtCwEDAQsBBQULDQ0hIhIBBQEKEgYTEgkHh2UImhsKjk+EUjCIfgIFDINrhCeDHQSCW4VTjD2NcD2BTX+BTg X-IronPort-AV: E=Sophos;i="4.71,319,1320620400"; d="scan'208";a="134495590" Received: from mail-iy0-f182.google.com ([209.85.210.182]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 08 Dec 2011 09:56:48 +0100 Received: by iafi7 with SMTP id i7so3660723iaf.27 for ; Thu, 08 Dec 2011 00:56:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=lQK/2aUkeDNnwWCeclMg/Dx6MfVXTi/80cxgkQFVsc8=; b=nN4ZW/qpw2MTuikRqC8fDeRg2nA06FJHDXW/HKycPk/AKsn4TRiCqwiyxSDqoTMAML jwB80XEngRZOkihTdRq8lg9ypwiyD5URe3lYRjR7XXUIue3aaGYlZk0tCtNPuC0u84pD n2vkHzdb2iUIqp5zbg03aKqwmIpcxZffGNxnA= Received: by 10.50.171.3 with SMTP id aq3mr2760845igc.49.1323334607191; Thu, 08 Dec 2011 00:56:47 -0800 (PST) MIME-Version: 1.0 Sender: warnegia@gmail.com Received: by 10.50.79.8 with HTTP; Thu, 8 Dec 2011 00:56:26 -0800 (PST) In-Reply-To: <4EE07A30.4090000@fugmann.net> References: <4EE07A30.4090000@fugmann.net> From: William Le Ferrand Date: Thu, 8 Dec 2011 00:56:26 -0800 X-Google-Sender-Auth: hwXxhzvrQz3mb3_cQHhY2vMfdC8 Message-ID: To: Anders Fugmann Cc: caml users Content-Type: multipart/alternative; boundary=e89a8f234a1f2e3dbf04b390d9fd Subject: Re: [Caml-list] Storing ocaml values outside ocaml's heap --e89a8f234a1f2e3dbf04b390d9fd Content-Type: text/plain; charset=ISO-8859-1 Hi Anders! How're you doing ? Thanks for the suggestion. We actually have a solution in production right now (www.besport.com) that relies on netshm. Unfortunately, the serialization / deserialization is killing the performance : about 200ms for a full request against 7ms for a simple Hashtbl lookup on our hardware. ocaml-everlasting did solve this performance bottleneck but we get unacceptable segmentation faults, and before debugging this library I'd rather learn about other approaches :) Best regards, William On Thu, Dec 8, 2011 at 12:49 AM, Anders Fugmann wrote: > Hi William, > > Have you tried netshm from ocamlnet library? It seems that it would fit > your requirements by placing memory outside the reach of the garbage > collector. > > Using netshm would require a lot of serialization / deserilization and > memory copying, which might not be that efficient if you access the cache a > lot. > > Regards > Anders Fugmann > > > > > On 12/08/2011 05:35 AM, William Le Ferrand wrote: > >> Dear list, >> >> We are building a cache in ocaml and we're wondering if it would make >> sense to store ocaml values outside the reach of the gc. (gc on a 20GB >> cache hangs the process for a second or so). >> >> To run some experiments, we wrote a small library >> (https://github.com/besport/**ocaml-everlasting) >> that exposes two >> functions, get and set. >> >> When inserting a value, we copy recursively the blocs outside of the >> reach of the gc (and put the resulting value in some C array). When >> getting the value, we simply pass the pointer to the copied value to the >> ocaml code (the structure is still coherent and the value is directly >> usable). We also wrote an "update" function that compare a new value >> with the existing value in cache, to avoid unnecessary memory >> allocation/deallocation. >> >> It does not seems very stable though, but I don't know if it is a bug in >> the update function or simply because this approach is not reasonable. >> Do you have any thoughts? Is there any clever way to build a large cache >> in an ocaml app ? >> >> Thanks in advance for any tips! >> >> Best >> >> William >> >> >> -- >> William Le Ferrand >> >> Mobile : (+1) (415) 683-1484 >> Web : http://williamleferrand.**github.com/ >> >> > >> >> > > -- > Caml-list mailing list. Subscription management and archives: > https://sympa-roc.inria.fr/**wws/info/caml-list > Beginner's list: http://groups.yahoo.com/group/**ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-**bugs > > -- William Le Ferrand Mobile : (+1) (415) 683-1484 Web : http://williamleferrand.github.com/ --e89a8f234a1f2e3dbf04b390d9fd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Anders!=A0

How're you doing ?=A0

Thanks for the suggestion. We actually have a solution in producti= on right now (www.besport.com) that = relies on netshm. Unfortunately, the serialization / deserialization is kil= ling the performance : about 200ms for a full request against 7ms for a sim= ple Hashtbl lookup on our hardware.=A0

ocaml-everlasting did solve this performance bottleneck= but we get unacceptable segmentation faults, and before debugging this lib= rary I'd rather learn about other approaches :)

Best regards,

William


On Thu, Dec 8, 2011 at 12:49 AM, Anders Fugmann <anders@fugmann.net> wrote:
Hi William,

Have you tried netshm from ocamlnet library? It seems that it would fit you= r requirements by placing memory outside the reach of the garbage collector= .

Using netshm would require a lot of serialization / deserilization and memo= ry copying, which might not be that efficient if you access the cache a lot= .

Regards
Anders Fugmann




On 12/08/2011 05:35 AM, William Le Ferrand wrote:
Dear list,

We are building a cache in ocaml and we're wondering if it would make sense to store ocaml values outside the reach of the gc. (gc on a 20GB
cache hangs the process for a second or so).

To run some experiments, we wrote a small library
(https://github.com/besport/ocaml-everlasting) that exposes two<= br> functions, get and set.

When inserting a value, we copy recursively the blocs outside of the
reach of the gc (and put the resulting value in some C array). When
getting the value, we simply pass the pointer to the copied value to the
ocaml code (the structure is still coherent and the value is directly
usable). We also wrote an "update" function that compare a new va= lue
with the existing value in cache, to avoid unnecessary memory
allocation/deallocation.

It does not seems very stable though, but I don't know if it is a bug i= n
the update function or simply because this approach is not reasonable.
Do you have any thoughts? Is there any clever way to build a large cache
in an ocaml app ?

Thanks in advance for any tips!

Best

William


--
William Le Ferrand

Mobile : (+1) (415) 683-1484
Web : htt= p://williamleferrand.github.com/
<http://www.linkedin.com/in/williamleferrand>



--
Caml-list mailing list. =A0Subscription management and archives:
https://sympa-roc.inria.fr/wws/info/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners<= /a>
Bug reports: http://caml.inria.fr/bin/caml-bugs




--
Willi= am Le Ferrand

Mobile :=A0(+1)=A0(415) 683-148= 4

--e89a8f234a1f2e3dbf04b390d9fd--