From: Till Varoquaux <till@pps.jussieu.fr>
To: Yaron Minsky <yminsky@gmail.com>
Cc: Will M Farr <farr@mit.edu>, "<caml-list@inria.fr>" <caml-list@inria.fr>
Subject: Re: [Caml-list] Optimizing Float Ref's
Date: Mon, 31 Aug 2009 10:09:42 -0400 [thread overview]
Message-ID: <9d3ec8300908310709l638fcf94l6a92e1ac4c98fb7f@mail.gmail.com> (raw)
In-Reply-To: <D27BEB0C-F919-4077-ABE6-36D20206CB34@gmail.com>
True. All float records and float arrays are unboxed so modifications
don't have to pass through caml_modify. A single cell array will still
have dynamic bound checking so I would recommend going for the record.
Till
On Sun, Aug 30, 2009 at 3:43 PM, Yaron Minsky<yminsky@gmail.com> wrote:
> Float refs are not unboxed automatically, because refs
> Are polymorphic containers. If you create your own pseudo-ref, i.e., a
> record with a single mutable float field, then I believe you should get the
> behaviour you expect.
>
> Come to think of it, I wonder if it would be better to implement ref on top
> of a single-cell array, since then everyone would get the float unboxing
> whenever applicable. I imagine there is some runtime overhead to this,
> though.
>
> y
>
>
> On Aug 28, 2009, at 4:32 PM, Will M Farr <farr@MIT.EDU> wrote:
>
>> Hello all,
>>
>> I'm running OCaml 3.11.1, and I noticed something strange in some native
>> code for matrix multiply today. The code was
>>
>> let mmmul store m1 m2 =
>> let (ni,nk) = dims m1 and
>> (nk2,nj) = dims m2 and
>> (sni,snj) = dims store in
>> assert(nk=nk2);
>> assert(ni=sni);
>> assert(nj=snj);
>> for i = 0 to ni - 1 do
>> let row1 = m1.(i) and
>> srow = store.(i) in
>> for j = 0 to nj - 1 do
>> let sum = ref 0.0 in (* Un-boxed float ref? *)
>> for k = 0 to nk - 1 do
>> let row2 = Array.unsafe_get m2 k in
>> let x = Array.unsafe_get row1 k and
>> y = Array.unsafe_get row2 j in
>> sum := !sum +. x*.y
>> done;
>> Array.unsafe_set srow j !sum
>> done
>> done;
>> store
>>
>> (I compiled with ocamlopt.) It multiplies the matrices (represented as
>> arrays of arrays of floats) m1 and m2 together and puts the result into the
>> matrix store. Profiling the code, I noticed a call to caml_modify during
>> the execution of this function! Turns out that the culprit was the float
>> ref "sum". Changing to the following code (which eliminates the float ref,
>> and uses the <- and .( ) operators instead of unsafe_set and unsafe_get)
>> eliminated that call, and sped things up tremendously:
>>
>> let mmmul store m1 m2 =
>> let (ni,nk) = dims m1 and
>> (nk2,nj) = dims m2 in
>> for i = 0 to ni - 1 do
>> let row1 = m1.(i) and
>> srow = store.(i) in
>> for j = 0 to nj - 1 do
>> srow.(j) <- 0.0;
>> for k = 0 to nk - 1 do
>> let row2 = Array.unsafe_get m2 k in
>> let x = row1.(k) and
>> y = row2.(j) in
>> srow.(j) <- srow.(j) +. x*.y
>> done
>> done
>> done;
>> store
>>
>> But, I thought that float ref's were automatically unboxed by the compiler
>> when they didn't escape the local context. Is this a complier bug, is there
>> a bad interaction with unsafe_get and unsafe_set, or is there something else
>> going on that I don't understand? Any enlightenment would be appreciated.
>>
>> Thanks!
>> Will
>> _______________________________________________
>> Caml-list mailing list. Subscription management:
>> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
>> Archives: http://caml.inria.fr
>> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>> Bug reports: http://caml.inria.fr/bin/caml-bugs
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>
next prev parent reply other threads:[~2009-08-31 14:09 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-28 20:32 Will M Farr
2009-08-30 19:43 ` [Caml-list] " Yaron Minsky
2009-08-31 14:09 ` Till Varoquaux [this message]
2009-08-31 14:51 ` Will M Farr
2009-08-31 17:30 ` Jon Harrop
2009-08-31 17:15 ` Jon Harrop
2009-09-03 9:44 ` Xavier Leroy
2009-09-03 10:15 ` Will M Farr
2010-03-31 17:21 ` Dmitry Bely
[not found] ` <p2tc7e4e9f1003311055xce0919wac2118aa3c05f1cb@mail.gmail.com>
2010-03-31 18:28 ` Dmitry Bely
2010-03-31 18:59 ` Alain Frisch
2010-03-31 19:18 ` Dmitry Bely
[not found] ` <m2lfbd71dab1003311252v5bda5d13vc2146d2d24270847@mail.gmail.com>
2010-03-31 20:00 ` Dmitry Bely
2010-04-14 18:13 ` Goswin von Brederlow
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=9d3ec8300908310709l638fcf94l6a92e1ac4c98fb7f@mail.gmail.com \
--to=till@pps.jussieu.fr \
--cc=caml-list@inria.fr \
--cc=farr@mit.edu \
--cc=yminsky@gmail.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).