From: Hal Daume III <hdaume@ISI.EDU>
To: caml-list@yquem.inria.fr
Subject: bigarrays much lower than normal ones
Date: Sun, 31 Oct 2004 08:05:46 -0800 (PST) [thread overview]
Message-ID: <Pine.LNX.4.44.0410310750180.22156-100000@albini.isi.edu> (raw)
I've been hitting the limiting size of normal float arrays and was having
a look at the Bigarray module. Unfortunately, it seems roughly 3-4 times
*slower* than the standard array, which is pretty much unacceptable for
me. Am I doing something naively wrong, or are the Bigarrays truly this
slow? The timing results I get (i686, redhat) are along the liens of:
stdarray, safe:
12.000u 0.030s 0:12.18 98.7% 0+0k 0+0io 107pf+0w
12.060u 0.030s 0:12.22 98.9% 0+0k 0+0io 107pf+0w
stdarray, unsafe:
11.990u 0.070s 0:12.21 98.7% 0+0k 0+0io 107pf+0w
12.130u 0.040s 0:12.31 98.8% 0+0k 0+0io 107pf+0w
bigarray, 64 bit:
39.760u 0.040s 0:40.35 98.6% 0+0k 0+0io 110pf+0w
39.750u 0.030s 0:40.09 99.2% 0+0k 0+0io 110pf+0w
bigarray, 32 bit:
41.950u 0.050s 0:42.60 98.5% 0+0k 0+0io 110pf+0w
42.070u 0.040s 0:42.53 99.0% 0+0k 0+0io 110pf+0w
(safe vs. unsafe is when compiled normally or with -unsafe; 64bit vs 32bit
is the 'kind' used for the bigarrays.)
I'm also really shocked that the 32 bit float bigarrays are slower than
the 64 bit ones!
Can someone explain this to me?
The code is:
<standard array>
open Array
let normalize a =
let s = fold_left (+.) 0. a in
for i = 0 to length a - 1 do
a.(i) <- a.(i) /. s;
done;
()
let _ =
let a = make 1000000 0. in
for iter = 1 to 100 do
for i = 0 to 999999 do
let i' = float_of_int i in
a.(i) <- log (0.01 *. i' *. i' +. 3. *. i' +. 4.);
done;
normalize a;
done;
()
<big array>
open Bigarray
let normalize a =
let _N = Array1.dim a in
let rec sum n acc =
if n >= _N then acc
else sum (n+1) (acc +. Array1.get a n) in
let s = sum 0 0. in
for i = 0 to _N - 1 do
Array1.set a i (Array1.get a i /. s);
done;
()
let _ =
let a = Array1.create float32 c_layout 1000000 in
for iter = 1 to 100 do
for i = 0 to 999999 do
let i' = float_of_int i in
Array1.set a i (log (0.01 *. i' *. i' +. 3. *. i' +. 4.));
done;
normalize a;
done;
()
If you put the array allocation inside the iter loop, nothing changes
much, relatively, on the timing results.
- Hal
--
Hal Daume III | hdaume@isi.edu
"Arrest this man, he talks in maths." | www.isi.edu/~hdaume
next reply other threads:[~2004-10-31 16:06 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-31 16:05 Hal Daume III [this message]
2004-10-31 17:26 ` [Caml-list] " John Prevost
2004-10-31 17:41 ` malc
2004-11-01 0:05 ` skaller
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=Pine.LNX.4.44.0410310750180.22156-100000@albini.isi.edu \
--to=hdaume@isi.edu \
--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