Version française
Home     About     Download     Resources     Contact us    
Browse thread
about OcamIL
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
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