caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
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


  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;
as well as URLs for NNTP newsgroup(s).