From: Jon Harrop <jon@ffconsultancy.com>
To: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Benchmarks against imperative languages
Date: Sun, 5 Mar 2006 11:54:07 +0000 [thread overview]
Message-ID: <200603051154.07774.jon@ffconsultancy.com> (raw)
In-Reply-To: <20060304143608.GA16996@ours.starynkevitch.net>
On Saturday 04 March 2006 14:36, Basile STARYNKEVITCH wrote:
> We all know (by experience) that Ocaml performs quite well. We also
> know that for most (but not all) of the software we are coding, the
> cost and time of development does significantly matter, and a 10%
> decrease in performance is not that important, hence Ocaml brings a
> real win.
Yes and no. I think the relative performance of OCaml is quite variable. Here
is a range of examples:
1. Straightforwardly-implemented algorithms can be vastly faster when written
in a functional style and optimising imperative equivalents can be tricky,
e.g. set theoretic operations and the "n"th-nearest neighbour example from my
ocaml book:
http://www.ffconsultancy.com/products/ocaml_for_scientists/complete/
2. Any problems that are near the limit of practical feasibility are likely to
benefit enormously from improved development time. This includes the limits
of computational complexity, memory usage and algorithm-implementation
complexity.
3. Floating-point intensive algorithms can be miraculously (IMHO) fast for an
FPL, e.g. my ray tracer benchmark on AMD (particularly AMD64):
http://www.ffconsultancy.com/free/ray_tracer/languages.html
4. Certain operations can be surprisingly slow, e.g. my Sudoku solver is
several times slower in OCaml because ocamlopt does not optimise integer div
or mod by a constant:
http://www.ffconsultancy.com/free/sudoku/
The relative development speed in OCaml and C++ is also quite variable. Some
applications, like compilers and interpreters, clearly benefit enormously
from languages like OCaml. Other applications, like small and simple
numerical programs (e.g. the ray tracer) benefit from the availability of
libraries like Blitz++ and Boost for C++. In the former case, development can
be an order of magnitude faster in OCaml. In the latter case, the time taken
to develop similar-performance programs can be roughly the same.
> A real answer would be to have a team of programmers fluent in Ocaml
> write a code (an real-sized application of hundreds of KLOC of source
> code, representing several man-years of effort) which has exactly the
> same precise specification than an existing code written in C. But
> this will never happen (it is too costly but quite useless an
> experiment). For example, nobody will recode in Ocaml an exact clone
> of gcc-4.1, firefox-1.5, or mysql-5.0!
I have cited my most relevant example before - a vector graphics library which
was 4x longer in C++, the worst-case performance was 5x faster in OCaml and
the development time was an order of magnitude faster in OCaml. It was a
rewrite from C++ to OCaml, so it is biased. However, I ditched C++ because it
was infeasible to do the rewrite in C++ and I have not looked back since.
Also, I can't say how OCaml compares to other FPLs. The code size was
~10kLOC.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists
next prev parent reply other threads:[~2006-03-05 11:52 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-04 14:04 Sarah Mount
2006-03-04 14:36 ` [Caml-list] " Basile STARYNKEVITCH
2006-03-04 18:01 ` David Teller
2006-03-05 9:38 ` Richard Jones
2006-03-05 14:38 ` Christophe TROESTLER
2006-03-05 4:48 ` Looking for suggestions on self-referential object definitions David Powers
2006-03-05 5:31 ` [Caml-list] " Jonathan Roewen
2006-03-05 14:37 ` David Powers
2006-03-05 8:21 ` Martin Jambon
2006-03-05 15:16 ` Oliver Bandel
2006-03-05 11:54 ` Jon Harrop [this message]
2006-03-05 13:20 ` [Caml-list] Benchmarks against imperative languages skaller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200603051154.07774.jon@ffconsultancy.com \
--to=jon@ffconsultancy.com \
--cc=caml-list@yquem.inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox