Browse thread
Comments welcomed to progr. style / speed of my first ocaml program "Error correcting LDPC decoder"
-
Andries Hekstra
-
Gerd Stolpmann
- Gerd Stolpmann
- Jon Harrop
-
Gerd Stolpmann
[
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: | 2005-12-15 (12:40) |
From: | Gerd Stolpmann <info@g...> |
Subject: | Re: [Caml-list] Comments welcomed to progr. style / speed of my first ocaml program "Error correcting LDPC decoder" |
I forgot one thing: This comment is only correct for 32 bit code. 64 bit code has a uniform array layout for all element types. Gerd Gerd Stolpmann said: > > Andries Hekstra said: >> Attached please find the first program I wrote. It has about the same >> speed as its C++ counterpart (slightly faster). I welcome comments >> w.r.t. >> programming style, esp. when it affects the speed of the program. > > As you are doing a lot of array manipulation, this tip may increase > performance significantly: because "float array" is stored with a > different layout than all other arrays, the compiler generates a dynamic > check for every access when the type of the array elements cannot be > statically determined. For example, your function > > let swapElement i j a = let x = a.(i) in a.(i) <- a.(j); a.(j) <- x > > is polymorphic in the element type. If you define instead > > let swapFloatElement i j (a : float array) let x = a.(i) in a.(i) <- > a.(j); a.(j) <- x > > better code is generated because the mentioned check can be omitted by the > compiler. This applies only if the function is not inlined; swapElement > could be small enough (but qsort, for instance, is definitely not). > > Unfortunately, one cannot define swapNonFloatElement because there is no > way to constrain a type that it is not float. So the type system cannot > represent this duality float/non-float, and one must fall back to as many > definitions as element types are actually used. > > Gerd > ------------------------------------------------------------ > Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany > gerd@gerd-stolpmann.de http://www.gerd-stolpmann.de > ------------------------------------------------------------ > > > _______________________________________________ > 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 > > ------------------------------------------------------------ Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany gerd@gerd-stolpmann.de http://www.gerd-stolpmann.de ------------------------------------------------------------