caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: "David McClain" <dmcclain1@mindspring.com>
To: <caml-list@inria.fr>
Subject: Re: [Caml-list] OCaml Speed for Block Convolutions
Date: Mon, 4 Jun 2001 13:15:00 -0700	[thread overview]
Message-ID: <002a01c0ed33$0b3d5de0$210148bf@dylan> (raw)
In-Reply-To: <15131.59080.327155.47983@beertje.william.bogus>

> I can easily imagine that, with two caveats: tuples passed directly to
> functions do seem to get elided, while on the other hand apparently
> atomic float accumulators can cause more garbage than you might think.

Actually, wherever I produce new data, I usually allocate an entirely new
array to hold the results. Then I use unsafe accesses like the following for
summing two arrays:

let dst = Array.unsafe_create nel in
for ix = 0 to pred nel do
    Array.unsafe_set dst ix ((Array.unsafe_get src1 ix) +. (Array.unsafe_get
src2 ix))
done;

I think the constant creation of new arrays to hold intermediate results
(i.e., immutable data) is costing too much. Many of the intermediate values
could be overwritten in place and save a lot of time.

... of course... don't ask how long it took to write all this stuff in the
inner loops of the convolution in C, nor how long it took to debug that
stuff.... And immutable data definitely helps to get the code correct. OCaml
still rules!

- DM

-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr


  parent reply	other threads:[~2001-06-04 20:13 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-06-04 13:25 David McClain
2001-06-04 19:51 ` William Chesters
2001-06-04 20:05   ` Chris Hecker
2001-06-04 20:15   ` David McClain [this message]
2001-06-04 22:34     ` Markus Mottl
2001-06-06 20:13       ` William Chesters
2001-06-06 22:29         ` Chris Hecker
2001-06-07  7:42           ` William Chesters
2001-06-05  7:22     ` Chris Hecker
2001-06-06  6:27       ` David McClain
2001-06-04 22:14   ` Tom _
2001-06-04 22:57     ` Chris Hecker
2001-06-05  2:52     ` Brian Rogoff
2001-06-05 15:02       ` Stefan Monnier
2001-06-05 10:48   ` Tom _
2001-06-06  2:03     ` Hugo Herbelin
2001-06-06  4:04       ` Charles Martin
2001-06-06 18:25         ` William Chesters
2001-06-06 18:35       ` William Chesters
2001-06-06 18:40         ` Patrick M Doane
2001-06-07  1:50         ` Hugo Herbelin
2001-06-07 18:20         ` Tom _
2001-06-07 23:49           ` [Caml-list] let mutable (was OCaml Speed for Block Convolutions) Jacques Garrigue
2001-06-08  0:20             ` [Caml-list] Currying in Ocaml Mark Wotton
2001-06-08 10:13               ` Anton Moscal
     [not found]             ` <Pine.LNX.4.21.0106081015000.1167-100000@hons.cs.usyd.edu.a u>
2001-06-08  0:38               ` Chris Hecker
2001-06-08  8:25             ` [Caml-list] let mutable (was OCaml Speed for Block Convolutions) Ohad Rodeh
2001-06-08 15:21               ` Brian Rogoff
2001-06-08 17:30             ` Pierre Weis
2001-06-08 18:36               ` Stefan Monnier
2001-06-08 19:07                 ` Pierre Weis
2001-06-08 19:30               ` Michel Quercia
2001-06-11  6:42                 ` [Caml-list] should "a.(i)" be a reference? (was "let mutable") Judicaël Courant
2001-06-11 13:42                 ` [Caml-list] let mutable (was OCaml Speed for Block Convolutions) Pierre Weis
2001-06-12  3:21                   ` Jacques Garrigue
2001-06-12  7:43                     ` Pierre Weis
2001-06-12  8:31                       ` Jacques Garrigue
2001-06-12 13:15                         ` Georges Brun-Cottan
2001-06-12 21:54                       ` John Max Skaller
2001-06-15  9:55               ` Michael Sperber [Mr. Preprocessor]
  -- strict thread matches above, loose matches on Subject: below --
2001-06-01 18:38 [Caml-list] OCaml Speed for Block Convolutions David McClain
2001-06-01 22:51 ` Tom _
2001-06-02  0:10   ` Stefan Monnier
2001-06-04 10:12     ` Jacques Garrigue

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='002a01c0ed33$0b3d5de0$210148bf@dylan' \
    --to=dmcclain1@mindspring.com \
    --cc=caml-list@inria.fr \
    /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).