Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] novice puzzled by speed tests
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: dolfi@z...
Subject: [Caml-list] novice puzzled by speed tests

Hi everybody,

I'm new to the list, and deeply impressed by the stability and speed of
OCaml, as well as its functional nature. My best congratulations to the

Toying around with 3.07, I found that ocamlopt.opt -unsafe (on Mandrake
9.1, Pentium 4, 2.4 GHz) actually produces slower code than ocamlopt.opt.
The program in question is a prime generator:

let count = 400000

let ptab =
  let ptab = Array.create count 0 in
  ( ptab.(0)<- 2; ptab.(1) <- 3; ptab.(2) <- 5; ptab );;

let rec loop nr toggle psize =
(   let max = truncate (sqrt (float nr)) in
    let rec floop i =
      if ptab.(i)>max then
        ( ptab.(psize) <- nr;
          loop (nr+toggle) (6-toggle) (succ psize) )
      else if nr mod ptab.(i) = 0 then
        loop (nr+toggle) (6-toggle) psize
        floop (succ i)
    in if psize<count then floop 2 else ()
) in loop 5 2 3;

Printf.printf "prime %d: %d\n" count ptab.(pred count);;

On my box, the corresponding C program (gcc -O3) is slightly slower than
the ocamlopt.opt compiled O'Caml program, but about 25-30% faster than the
-unsafe one:

#include <stdio.h>
#include <math.h>

#define how_many 400000

int main()
{   unsigned int nr = 5, toggle = 2, max, primes_size = 3, i;
    unsigned int primes[how_many];

    primes[0] = 2; primes[1] = 3; primes[2] = 5;
    nr += toggle; toggle = 6 - toggle;
    max = sqrt(nr);
    for (i = 2; primes[i] <= max; ++i)
        if (!(nr % primes[i])) goto loop;
    primes[primes_size++] = nr;
    if (primes_size < how_many) goto loop;

    printf("%i\n", primes[how_many - 1]);
    return 0;

Of course it's good that range checking increases the speed of programs,
but, being a long-time C user, I'm a little bit puzzled by miracles like
this. I suspected that the sense of the -unsafe flag was inverted, but it
isn't: the -unsafe program dies with SEGV when I deliberately introduce a
range overflow, the safe one gets an exception.

Till soon, Dolfi

To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: