From: Jon Harrop <jon@ffconsultancy.com>
To: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Performance questions, -inline, ...
Date: Sat, 5 Jan 2008 19:36:23 +0000 [thread overview]
Message-ID: <200801051936.23521.jon@ffconsultancy.com> (raw)
In-Reply-To: <200801031128.30183.ober.14@osu.edu>
Optimizing numerical code is discussed in detail in my book OCaml for
Scientists. You may also be interested in a very similar thread where I
optimized someone's almost identical code on the beginners list recently.
There is also this relevant blog post of mine:
http://ocamlnews.blogspot.com/2007/09/spectral-norm.html
Essentially, your benchmark has rediscovered the fact that abstractions (HOFs,
polymorphism etc.) are prohibitively slow for high-performance numerics and
must be avoided. There are also some minor boxing issues at play.
On Thursday 03 January 2008 16:28:30 Kuba Ober wrote:
> I haven't looked at assembly output yet, but I've run into some unexpected
> behavior in my benchmarks.
Your benchmarks aren't sufficiently well defined to convey information about
anything specific, so you're highly likely to misinterpret what you see.
> This was compiled by ocamlopt -inline 100 -unsafe,
You should use Array.unsafe_get and _set rather than the command-line
option -unsafe because the latter breaks correct code.
> What I wonder is why vector-to-vector add is so much faster than (constant)
> scalar to vector add. Vectors are preinitialized each time with a 1.0000,
> 1.0001, ... sequence.
This is also highly likely to be platform and architecture dependent.
> Also, the very bad performance from generic vector-to-vector *with*
> inlining is another puzzler, whereas generic add of scalar-to-scalar
> performs similarly to straight-coded one.
>
> Cheers, Kuba
>
> * add1: add scalar to scalar 120 MIPS
> * add3: add scalar to vector 250 MIPS
> * add5: add vector to vector 320 MIPS
> * add2: generic add scalar to scalar 100 MIPS
> * add4: generic add vector to vector 38 MIPS
>
> let start = 1.3
>
> (* generic scalar operation *)
> let op1 op const nloop =
> let accum = ref start in
> for i = 1 to nloop do
> accum := op !accum const
> done
You probably meant to return "!accum".
> (* generic vector operation *)
> let op2 op const a b (nloop : int) =
> let len = Array.length a in
> for j = 0 to len-1 do
> for i = 0 to len-1 do
> b.(i) <- op a.(i) b.(i)
> done;
> done
>
> (** addition **)
> let add1 nloop =
> let accum = ref start in
> for i = 1 to nloop do
> accum := !accum +. addconst
> done
Again, should probably return "!accum". However, you can encourage OCaml to
unbox the float by returning "!accum + 0.0" instead.
> let add2 = op1 ( +. ) addconst
This should be slower than "add1".
> let add3 a b nloop =
> let len = Array.length a in
> for j = 0 to len-1 do
> for i = 0 to len-1 do
> b.(i) <- a.(i) +. addconst
> done;
> done
The loop over "j" can be removed.
> let add4 = op2 ( +. ) addconst
This will be slow because "op2" is polymorphic and "+." will not be inlined.
> let add5 a b nloop =
> let len = Array.length a in
> for j = 0 to len-1 do
> for i = 0 to len-1 do
> b.(i) <- a.(i) +. b.(i)
> done;
> done
This increments "b" by "a" many times. Replace the repeated adds with a single
multiply for each element.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e
next prev parent reply other threads:[~2008-01-05 19:44 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-03 16:28 Kuba Ober
2008-01-03 17:11 ` [Caml-list] " Edgar Friendly
2008-01-05 18:09 ` Kuba Ober
2008-01-05 18:44 ` Kuba Ober
2008-01-05 19:36 ` Jon Harrop [this message]
2008-01-05 20:31 ` Bünzli Daniel
2008-01-07 13:48 ` Kuba Ober
2008-01-07 14:41 ` Jon Harrop
2008-01-07 15:22 ` Kuba Ober
2008-01-07 19:58 ` Jon Harrop
2008-01-08 14:20 ` Kuba Ober
2008-01-12 14:22 ` Jon Harrop
2008-01-12 16:18 ` Dario Teixeira
2008-01-12 23:50 ` Jon Harrop
2008-01-07 15:31 ` Christophe Raffalli
2008-01-07 17:00 ` Jacques Carette
2008-01-07 17:07 ` Till Varoquaux
2008-01-07 17:20 ` Jacques Carette
2008-01-07 17:31 ` Kuba Ober
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=200801051936.23521.jon@ffconsultancy.com \
--to=jon@ffconsultancy.com \
--cc=caml-list@yquem.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