From: Bob Atkey <bob.atkey@gmail.com>
To: Mark Shinwell <mshinwell@janestreet.com>
Cc: "caml-list@inria.fr" <caml-list@inria.fr>
Subject: Re: [Caml-list] ANN: unboxed-arrays-0.1: Unboxed arrays for OCaml
Date: Mon, 20 Jan 2014 12:24:01 +0000 [thread overview]
Message-ID: <CA+aevF854qoh03w9dhbso3QLWSqY9UvKcDjZpgob-u3ccg=_aw@mail.gmail.com> (raw)
In-Reply-To: <CAM3Ki762WFuxD5O50jvYDuJy_TcWrNKKX_wen4UncTqr9pa9fA@mail.gmail.com>
On 20 January 2014 08:47, Mark Shinwell <mshinwell@janestreet.com> 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 = Flat_array.create 10 "hello";;
val s : string Flat_array.t = <abstr>
# Flat_array.element_at s ~index:0;;
- : string =
"hello\000\000\002\249\b\000\000\000\000\000\000hello\000\000\002\249\016\000\000\000\000\000\000hello\000\000\002\249\024\000\000\000\000\000\000hello\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 = Flat_array.create 10 [|1;2;3|];;
val t : int array Flat_array.t = <abstr>
# Flat_array.element_at t ~index:0;;
- : int array =
[|1; 2; 3; 2172; 1; 2; 3; 4220; 1; 2; 3; 6268; 1; 2; 3; 8316; 1; 2; 3; 10364;
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 =
[|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
next prev parent reply other threads:[~2014-01-20 12:24 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-19 18:01 Bob Atkey
2014-01-20 8:47 ` Mark Shinwell
2014-01-20 12:24 ` Bob Atkey [this message]
2014-01-20 12:33 ` Mark Shinwell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CA+aevF854qoh03w9dhbso3QLWSqY9UvKcDjZpgob-u3ccg=_aw@mail.gmail.com' \
--to=bob.atkey@gmail.com \
--cc=caml-list@inria.fr \
--cc=mshinwell@janestreet.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).