English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
[Caml-list] Where does Ocaml spend all the time?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2001-06-28 (08:37)
From: Xavier Leroy <Xavier.Leroy@i...>
Subject: Re: [Caml-list] Where does Ocaml spend all the time?
> I have written an ocaml program, which is about an order of magnitude
> slower than a similar C program, and now I am wondering what to do.
> According to gprof, I have neiter written nor called most of the
> top-scoring functions in my program:
> Only the third and fourth entry seem to do anything "useful", the rest
> looks like administrative overhead to me. What are these functions
> doing?

mark_slice and sweep_slice are the major garbage collector.
oldify is the minor garbage collector.
string_equal is the string comparison operator (i.e. Caml's = operator
at type string->string->bool).

> Are there any general hints on how to write ocaml programs for efficiency?
> Like, don't use functional updates for records to reduce garbage?

That might be a possibility, depending on the size of the records.
However, heap allocation of short-lived data structures is quite cheap,
while some forms of in-place updates can be quite expensive
(in particular, storing a pointer to a young object in an old object).
So, the answer is not clear-cut.

At any rate, the GC-related functions account for only 25% of the
running time (which is typical for symbolic processing, but a bit high
for numerical processing), so the "order of magnitude" slowdown that
you mention corresponds to other factors than just GC overhead.
My experience is that carefully written Caml code always deliver at
least 50% of the performance of equivalent, carefully written C code.

It is true, however, that tuning Caml code for performance is not
obvious without a good knowledge of the compiler internals.  However,
the "making code run fast" section of the OCaml Questions and Answers
might help:

- Xavier Leroy
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr