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 BEA387EE99 for ; Mon, 20 Jan 2014 13:24:02 +0100 (CET) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of bob.atkey@gmail.com) identity=pra; client-ip=209.85.215.47; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="bob.atkey@gmail.com"; x-sender="bob.atkey@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of bob.atkey@gmail.com designates 209.85.215.47 as permitted sender) identity=mailfrom; client-ip=209.85.215.47; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="bob.atkey@gmail.com"; x-sender="bob.atkey@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-la0-f47.google.com) identity=helo; client-ip=209.85.215.47; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="bob.atkey@gmail.com"; x-sender="postmaster@mail-la0-f47.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwDAEIU3VLRVdcvlWdsb2JhbABWA4QZuz2BBQgWDgEBAQEHDQkJEiqCJQEBAQRAARsdAQMMBgULAwouIgERAQUBHAYTh3ABAxGbaoxcgwmRWwoZJw1khHIRAQUMjgc5IxAHEYQnBJgikCsYKYRZPIE1 X-IPAS-Result: AhwDAEIU3VLRVdcvlWdsb2JhbABWA4QZuz2BBQgWDgEBAQEHDQkJEiqCJQEBAQRAARsdAQMMBgULAwouIgERAQUBHAYTh3ABAxGbaoxcgwmRWwoZJw1khHIRAQUMjgc5IxAHEYQnBJgikCsYKYRZPIE1 X-IronPort-AV: E=Sophos;i="4.95,690,1384297200"; d="scan'208";a="54003999" Received: from mail-la0-f47.google.com ([209.85.215.47]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 20 Jan 2014 13:24:02 +0100 Received: by mail-la0-f47.google.com with SMTP id el20so2929968lab.6 for ; Mon, 20 Jan 2014 04:24:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=LMqHfcZ8Ysl5kGenW5ObmQ2Tke8uyz4edbGiHuFuPj4=; b=bmgBvGHG/pY7KueuRLtX33OJB91G6R/Eo45UFdgVLCBRgYRjegcWyGXS3EBhtqS7nk e6OFRO0LAdjBNtcj1v4Q+yqmriZgFNi7yjM5YQEGVnFFUYiHJK2hN3vVUHfhELLcAXXR 5605rQDILtT5ctgnbZiSZShqZVbuZgA9QSE7IC9no39zuzMH5AwLcNg5Rh1luPKMfY6o PvlWI872N3rqad43RZM3NJOqkabsLH17wD4WL2mVN4hK1Z8ueAvGcDrvo+j3r2Lpqnus RhR5lyqaXWJYtPFmYcrWWzMhiHUjCuZ9Me5Xu31oGe3wCn4J4cjqimj3ptjkxG9Abwfd kwkg== MIME-Version: 1.0 X-Received: by 10.152.170.199 with SMTP id ao7mr1221097lac.40.1390220641430; Mon, 20 Jan 2014 04:24:01 -0800 (PST) Received: by 10.112.57.195 with HTTP; Mon, 20 Jan 2014 04:24:01 -0800 (PST) In-Reply-To: References: Date: Mon, 20 Jan 2014 12:24:01 +0000 Message-ID: From: Bob Atkey To: Mark Shinwell Cc: "caml-list@inria.fr" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Caml-list] ANN: unboxed-arrays-0.1: Unboxed arrays for OCaml On 20 January 2014 08:47, Mark Shinwell wrote: > Thanks for sharing your code. I also did an experiment > with this recently (although I would argue that it isn't always > clear that flat arrays are desirable). My flat array module > is designed to hold a sequence of values of record type. Pointers > to the records may be retrieved and then normal mutable field > updates may be used to change them. This looks really useful. Especially the fact that your implementation has no allocation overhead when accessing an element in the array. unboxed-arrays definitely has allocation overhead, and also an interpretation overhead when reading and writing. Maybe these could be mitigated with enough inlining though. > (In case you are wondering, > if you put some other variety of value in the array, then it's > probably safe but won't be useful---since in particular there > is no "set" method provided.) Unfortunately, Flat_array seems to go a bit awry when you put strings or arrays in as the default element: (OCaml 4.01.0) # let s =3D Flat_array.create 10 "hello";; val s : string Flat_array.t =3D # Flat_array.element_at s ~index:0;; - : string =3D "hello\000\000\002\249\b\000\000\000\000\000\000hello\000\000\002\249\016\0= 00\000\000\000\000\000hello\000\000\002\249\024\000\000\000\000\000\000hell= o\000\000\002\249 \000\000\000\000\000\000hello\000\000\002\249(\000\000\000\000\000\000hello= \000\000\002\2490\000\000\000\000\000\000hello\000\000\002\2498\000\000\000= \000\000\000hello\000\000\002\249@\000\000\000\000\000\000hello\000\000\002= \249H\000\000\000\000\000\000hello\000\000\002!\000\000\000\000\000\000" # let t =3D Flat_array.create 10 [|1;2;3|];; val t : int array Flat_array.t =3D # Flat_array.element_at t ~index:0;; - : int array =3D [|1; 2; 3; 2172; 1; 2; 3; 4220; 1; 2; 3; 6268; 1; 2; 3; 8316; 1; 2; 3; 1036= 4; 1; 2; 3; 12412; 1; 2; 3; 14460; 1; 2; 3; 16508; 1; 2; 3; 18556; 1; 2; 3; 32|] Even worse, because it is accessing memory off the end of the block allocated by Flat_array: # Flat_array.element_at t ~index:9;; - : int array =3D [|1; 2; 3; 32; 1920; 1; 2; 3; 1019; 19742592; 2043; 70323357739924; 70323353168284; 70323352779268; 2555; 70323357739208; 70323353168344; 70323353168448; 0; 1019; 70323357739294; 1408; 70323358792352; 70323358792376; 1408; 5224; 70323358798112; 1408; 5225; 70323352741540; 1408; 70323358792388; 0; 1408; 5223; 70323358796124|] I can see how one might detect at runtime that a string is being used as the default element, but I'm not sure if there is a way to tell the difference between arrays, tuples and records at runtime. I thought that it might be possible to get a segfault during GC by putting a string full of 0 bytes in, but I wasn't able to actually make this happen. Bob