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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 394FA7F6CD for ; Thu, 5 Feb 2015 11:51:00 +0100 (CET) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of alain.frisch@lexifi.com) identity=pra; client-ip=85.233.204.164; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="alain.frisch@lexifi.com"; x-sender="alain.frisch@lexifi.com"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of alain.frisch@lexifi.com) identity=mailfrom; client-ip=85.233.204.164; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="alain.frisch@lexifi.com"; x-sender="alain.frisch@lexifi.com"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mx20.yaziba.net) identity=helo; client-ip=85.233.204.164; receiver=mail2-smtp-roc.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: A0DkAAA6StNUnKTM6VVayh6CTwKBJEMBAQEBAREBAQEBAQYNCQkULoQNAQU4QBELGAkWDwkDAgECAUUGAQwIAQGILdYGAQoBAQEejzMSOoQpBZg+gReFKIhtgzwChBGDMAEBAQ X-IPAS-Result: A0DkAAA6StNUnKTM6VVayh6CTwKBJEMBAQEBAREBAQEBAQYNCQkULoQNAQU4QBELGAkWDwkDAgECAUUGAQwIAQGILdYGAQoBAQEejzMSOoQpBZg+gReFKIhtgzwChBGDMAEBAQ X-IronPort-AV: E=Sophos;i="5.09,523,1418079600"; d="scan'208";a="120384669" Received: from mx20.yaziba.net ([85.233.204.164]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/ADH-AES256-SHA; 05 Feb 2015 11:50:59 +0100 Received: from mta10.int.yaziba.net (unknown [10.4.20.30]) by mx20.yaziba.net (mx10.yaziba.net) with ESMTP id 310A71A74E7; Thu, 5 Feb 2015 11:50:59 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mta10.int.yaziba.net (Postfix) with ESMTP id 362AACA656; Thu, 5 Feb 2015 11:50:57 +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 y6IEU4Ix0QP8; Thu, 5 Feb 2015 11:50:56 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mta10.int.yaziba.net (Postfix) with ESMTP id B8FD0CA65B; Thu, 5 Feb 2015 11:50:35 +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 sfKMbdtQWhKD; Thu, 5 Feb 2015 11:50:35 +0100 (CET) Received: from [10.0.48.165] (unknown [185.23.92.144]) by mta10.int.yaziba.net (Postfix) with ESMTPSA id B95F1CA659; Thu, 5 Feb 2015 11:50:27 +0100 (CET) Message-ID: <54D34AF2.1010001@lexifi.com> Date: Thu, 05 Feb 2015 11:50:26 +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: =?windows-1252?Q?Pierre-Marie_P=E9drot?= , caml-list@inria.fr References: <20150202103256.GA30053@birba.invalid> <54D33020.6010707@lexifi.com> <54D33EC3.2050809@inria.fr> In-Reply-To: <54D33EC3.2050809@inria.fr> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-DRWEB-SCAN: ok X-VRSPAM-SCORE: -100 X-VRSPAM-STATE: legit X-VRSPAM-CAUSE: gggruggvucftvghtrhhoucdtuddrfeejkedrheefgddulecutefuodetggdotefrucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepkfffhfhofgggvffufhgjtgfgsehtqhgrtddtfeehnecuhfhrohhmpeetlhgrihhnucfhrhhishgthhcuoegrlhgrihhnrdhfrhhishgthheslhgvgihifhhirdgtohhmqe X-VRSPAM-EXTCAUSE: mhhouggvpehsmhhtphhouhht Subject: Re: [Caml-list] unmarshaling large data from string on 32 bits On 02/05/2015 10:58 AM, Pierre-Marie P=E9drot 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 (=E0 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=20 hope you know precisely which values go into the closures or not=20 (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=20 specific data types avoid some runtime checks required by the generic=20 functions (for the block tags and sizes, for detecting possible sharing=20 everywhere) and can use more specialized (and thus more compact) data=20 representation. We have had that problem at LexiFi, where we used to rely on the generic=20 marshaling for exchanges messages between processes (hence the ticket I=20 referred to). We finally decided to write (manually) specialized=20 functions for our type of messages (no closures, no sharing), and the=20 performance results where slower but reasonable compared to the generic=20 marshaling (without putting too much engineering effort into it). Anyway: - our previous workaround was to trigger Gc.compact explicitly for big=20 messages, which was much worse, of course; - it's clear that the OCaml implementation of the generic demarshaler=20 would be slower; - since this only impacts 32-bit systems, nobody seems motivated=20 enough to put energy into fixing the core issue. Alain