From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 04A347F6CC for ; Thu, 5 Feb 2015 13:25:00 +0100 (CET) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of alain.frisch@lexifi.com) identity=pra; client-ip=85.233.204.164; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="alain.frisch@lexifi.com"; x-sender="alain.frisch@lexifi.com"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of alain.frisch@lexifi.com) identity=mailfrom; client-ip=85.233.204.164; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="alain.frisch@lexifi.com"; x-sender="alain.frisch@lexifi.com"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mx20.yaziba.net) identity=helo; client-ip=85.233.204.164; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="alain.frisch@lexifi.com"; x-sender="postmaster@mx20.yaziba.net"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DxAADWYNNUnKTM6VVag1hZgwGvfo9NhXECgSRDAQEBAQERAQEBAQEICwkJFC6EDQEFIxU2CxALGAICBQQdAgIPAjQEAQ0GDQEFAgEBDogHAxUJvzqQVwOFYAEBAQEBBQEBAQEBAQEbgSGOABISMweCaIFBBYRMCo4OhVqBFzaEcohtgzwChBFuAYECgT8BAQE X-IPAS-Result: A0DxAADWYNNUnKTM6VVag1hZgwGvfo9NhXECgSRDAQEBAQERAQEBAQEICwkJFC6EDQEFIxU2CxALGAICBQQdAgIPAjQEAQ0GDQEFAgEBDogHAxUJvzqQVwOFYAEBAQEBBQEBAQEBAQEbgSGOABISMweCaIFBBYRMCo4OhVqBFzaEcohtgzwChBFuAYECgT8BAQE X-IronPort-AV: E=Sophos;i="5.09,523,1418079600"; d="scan'208";a="98973921" Received: from mx20.yaziba.net ([85.233.204.164]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/ADH-AES256-SHA; 05 Feb 2015 13:24:56 +0100 Received: from mta10.int.yaziba.net (unknown [10.4.20.30]) by mx20.yaziba.net (mx10.yaziba.net) with ESMTP id 62E8A1A748D; Thu, 5 Feb 2015 13:24:55 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mta10.int.yaziba.net (Postfix) with ESMTP id 4EF2ECA656; Thu, 5 Feb 2015 13:24:55 +0100 (CET) X-Virus-Scanned: amavisd-new at mta10.int.yaziba.net Received: from mta10.int.yaziba.net ([127.0.0.1]) by localhost (mta10.int.yaziba.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yxB-3LEJZDZv; Thu, 5 Feb 2015 13:24:55 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mta10.int.yaziba.net (Postfix) with ESMTP id 10E74CA659; Thu, 5 Feb 2015 13:24:55 +0100 (CET) X-Virus-Scanned: amavisd-new at mta10.int.yaziba.net Received: from mta10.int.yaziba.net ([127.0.0.1]) by localhost (mta10.int.yaziba.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id v1-TI2qLBMRq; Thu, 5 Feb 2015 13:24:54 +0100 (CET) Received: from [10.0.48.165] (unknown [185.23.92.144]) by mta10.int.yaziba.net (Postfix) with ESMTPSA id AE4F0CA657; Thu, 5 Feb 2015 13:24:54 +0100 (CET) Message-ID: <54D36116.70509@lexifi.com> Date: Thu, 05 Feb 2015 13:24:54 +0100 From: Alain Frisch Organization: LexiFi User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Fabrice Le Fessant CC: =?UTF-8?B?UGllcnJlLU1hcmllIFDDqWRyb3Q=?= , Ocaml Mailing List References: <20150202103256.GA30053@birba.invalid> <54D33020.6010707@lexifi.com> <54D33EC3.2050809@inria.fr> <54D34AF2.1010001@lexifi.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-DRWEB-SCAN: ok X-VRSPAM-SCORE: -51 X-VRSPAM-STATE: legit X-VRSPAM-CAUSE: gggruggvucftvghtrhhoucdtuddrfeejkedrheefgdefkecutefuodetggdotefrucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnegoufhushhpvggtthffohhmrghinhculdegledmnecujfgurhepkfffhfhofgggvffufhgjtgfgsehtqhgrtddtfeejnecuhfhrohhmpeetlhgrihhnucfhrhhishgthhcuoegrlhgrihhnrdhfrhhishgthheslhgvgihifhhirdgtohhmqeenucffohhmrghinhephigrhhhoohdrtghomhdpohgtrghmlhhprhhordgtohhmpdhinhhrihgrrdhfrh X-VRSPAM-EXTCAUSE: mhhouggvpehsmhhtphhouhht Subject: Re: [Caml-list] unmarshaling large data from string on 32 bits Hello Fabrice, While it's certainly interesting to extend the size of strings (and it=20 would solve the original problem), it would not address the problem=20 related to unmarshaling large data on 32-bit systems. Alain On 02/05/2015 01:22 PM, Fabrice Le Fessant wrote: > Hi, > > A long time ago, we had a patch on 32 bit systems to transparently > extend the size of strings and arrays over the 16 MB limit: > > http://www.ocamlpro.com/blog/2011/05/06/longval.html > > At the time, there was little interest in this patch. If I remember > well, it was quite small, we could probably include it in the next > version of OCPWin32, if you think having it under Windows would help > you. > > --Fabrice > > > On Thu, Feb 5, 2015 at 11:50 AM, Alain Frisch w= rote: >> On 02/05/2015 10:58 AM, Pierre-Marie P=C3=A9drot wrote: >>> >>> On 05/02/2015 09:56, Alain Frisch wrote: >>>> >>>> One possible work-around is to use an alternative implementation of the >>>> demarshaler (there is such a pure OCaml implementation in Frama-C). >>>> Another is to avoid the generic marshaling, either by writing a manual >>>> version for your specific data type or by generating it from your type >>>> definitions (=C3=A0 la bin-prot, I assume). >>> >>> >>> Both workarounds would not work. Indeed, we use closure marshalling in >>> Coq, which is not supported by the two proposed implementations. >> >> >> Waow, closure marshaling across processes: you live dangerously :-) I h= ope >> you know precisely which values go into the closures or not (exception >> slots, global mutable data structures, etc)... >> >> >>> (Plus, that would be so slow I do not even want to think about it.) >> >> >> I'm not so sure. Serialization/deserialization routines specialized for >> specific data types avoid some runtime checks required by the generic >> functions (for the block tags and sizes, for detecting possible sharing >> everywhere) and can use more specialized (and thus more compact) data >> representation. >> >> We have had that problem at LexiFi, where we used to rely on the generic >> marshaling for exchanges messages between processes (hence the ticket I >> referred to). We finally decided to write (manually) specialized functi= ons >> for our type of messages (no closures, no sharing), and the performance >> results where slower but reasonable compared to the generic marshaling >> (without putting too much engineering effort into it). Anyway: >> >> - our previous workaround was to trigger Gc.compact explicitly for big >> messages, which was much worse, of course; >> >> - it's clear that the OCaml implementation of the generic demarshaler = would >> be slower; >> >> - since this only impacts 32-bit systems, nobody seems motivated enoug= h to >> put energy into fixing the core issue. >> >> >> Alain >> >> >> -- >> Caml-list mailing list. Subscription management and archives: >> https://sympa.inria.fr/sympa/arc/caml-list >> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners >> Bug reports: http://caml.inria.fr/bin/caml-bugs > > >