Browse thread
[Caml-list] OCaml Speed for Block Convolutions
-
David McClain
- William Chesters
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | William Chesters <williamc@p...> |
| Subject: | [Caml-list] OCaml Speed for Block Convolutions |
David McClain writes:
> ....well, I hate to say this... but I did recode the innermost loop in C and
> it now runs more than 5 times faster... Straight recoding into C bought 4x,
> and using better math brought that up to 5x.
>
> I think the big thing here is that the OCaml code was producing huge amounts
> of garbage, despite preallocated buffers with which all the processing was
> reading and writing data. The ancillary closures and tuple args were just
> eating my shirt...
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.
E.g.
let a = ref 0. in
for i = 0 to n-1 do
a := !a +. Array.unsafe_get xs i
done
makes garbage---`a' isn't unboxed---while
type floatref = { mutable it: float }
let a = { it = 0. } in
for i = 0 to n-1 do
a := !a +. Array.unsafe_get xs i
done
doesn't. The effect on the visible quality of the assembler for the
inner loop is dramatic, and so is the speed improvement ... basically
using polymorphic data structures is a bad idea. I wonder if this is
a limitation you have run up against?
Some years ago I made a library using camlp4 for supporting tensor
notation, e.g.
tens x[I] = a[I J] b[J]
using both automatically generated C and vanilla caml. When I
recently noticed the above point about not using polymorphic
references, I found there was rather little difference in performane
between the C and ocaml versions.
-------------------
To unsubscribe, mail caml-list-request@inria.fr. Archives: http://caml.inria.fr