Browse thread
about OcamIL
-
ben kuin
- Alain Frisch
-
Eray Ozkural
- Ed Keith
- ben kuin
[
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: | 2010-05-19 (16:48) |
From: | Goswin von Brederlow <goswin-v-b@w...> |
Subject: | Re: [Caml-list] Re: about OcamIL |
Eray Ozkural <examachine@gmail.com> writes: > On the other hand, Jon's notion of high performance is valid I think. > You want to be as close to the metal as possible. Otherwise there is > no point in, say, writing a parallel version of the code. In the past > we thought that was only possible with C and Fortran. Nowadays we > think of C++ when we say that but I gladly find that ocaml is on par > with any of those for real world tasks, without requiring tedious and > cumbersome optimizations just to get it running (like in Java). The thing about ocaml is that it does not optimize. You get what you tell it to do. You put garbage in you get garbage out. You improve your algorithm you get a huge speedup. You don't get sudden and unexpected side effects that magically double your speed when you add a useless line of code somewhere because suddenly the compiler sees an optimization. Ocaml also finds a lot more bugs due to its stronger types and has much nicer look&feel for many problems imho. So you get your code written faster, looking better, working right and still have fun. If I finished writing a program (in basically any language) and find it runs too slow I have two avenues to optimize it: 1) Think of some algortihm that is more clever. That can easily improve performance by magnitudes. 2) Locate the part that sucks up all the time for no work being done and write some C/asm stubs that are specifically optimized. Except for extrem cases this tends to give little improvement. But that might be just me. MfG Goswin