Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: Gerd Stolpmann <Gerd.Stolpmann@darmstadt.netsurf.de>
To: caml-list@inria.fr
Subject: Re: speed versus C
Date: Tue, 5 Oct 1999 22:20:59 +0200	[thread overview]
Message-ID: <99100522193302.17263@ice> (raw)
In-Reply-To: <000f01bf0de7$2f626fd0$240cbed4@jannt>

On Sun, 03 Oct 1999, Jan Brosius wrote:
>Hi, is there anything known about the efficiency of compiled Ocaml code
>compared with C/C++

A good comparision of the low-level features of Ocaml and C are my
implementations of the cryptographic algorithms Blowfish and DES. Such
algorithms do many integer calculations, bit shifting, and array lookups, i.e.
tasks where C is perfect, and Ocaml is not designed for. The manually optimized
algorithms are 8 to 10 times slower than the C counterparts, and a factor of 2
can be explained with Ocaml's problems when computing with 32 bit numbers. To
get around this, all 32 bit calculations are simulated by doing them on two 16
bit halves. If such problems do not play a role, Ocaml is at most 4 to 5 times
slower than C.

As already pointed out, Ocaml is not designed for such problems, and this
slow-down factor is an upper limit. The typical application will have a speed
which is comparable with C/C++ solutions, as there are a number of advantages:

- The recursive data types of Ocaml are often more problem-oriented than
  "imperative" data structures. Consider you want to fill an (C) array with an
  unknown number of elements. The typical solution puts the elements into the
  array until it is full, and then enlarges the array by reallocating new
  memory. If you use the Ocaml lists instead, you do not have this problem. Of
  course, you can program linked lists in C, too, but they are not as
  convenient as arrays are, so many people avoid them. I think this is a very
  common problem in C where algorithms on static structures are cheap, and
  algorithms working with dynamic structures are either complicated (but fast),
  or calculate the same several times (but are simple to understand), or use
  sophisticated but heavy-weight libraries (with a complex interface). This is
  a bad alternative. Considering all of simplicity, time and space comsumption,
  I would say that Ocaml scales better.

- OCaml code expresses the same with fewer lines of code, so it is possible to
  write more complicated solutions, and to prefer a more sophisticated approach 
  over the straight-forward solution.

- Memory management is much better; but this counts only for long-running
  applications. Many C/C++ programs only "malloc" and do not "free", so the
  time consumption of these functions isn't a problem.

Gerd

--
----------------------------------------------------------------------------
Gerd Stolpmann      Telefon: +49 6151 997705 (privat)
Viktoriastr. 100             
64293 Darmstadt     EMail:   Gerd.Stolpmann@darmstadt.netsurf.de (privat)
Germany                     
----------------------------------------------------------------------------




  parent reply	other threads:[~1999-10-06 14:16 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-10-03 21:35 Jan Brosius
1999-10-04 21:59 ` skaller
1999-10-05 23:22   ` chet
1999-10-06 10:22     ` skaller
1999-10-05 20:20 ` Gerd Stolpmann [this message]
1999-10-06 15:21   ` William Chesters
1999-10-06 22:49     ` Gerd Stolpmann
1999-10-07 10:26       ` Michel Quercia
1999-10-07 10:46       ` William Chesters
1999-10-07 15:48         ` Pierre Weis
1999-10-07 19:21         ` Gerd Stolpmann
1999-10-08  0:26           ` William Chesters
1999-10-10 16:27             ` Gerd Stolpmann
1999-10-10 20:48               ` William Chesters
1999-10-10 23:54                 ` Alain Frisch
1999-10-11 17:58                   ` William Chesters
1999-10-12 14:36                     ` Ocaml Machine (was Re: speed versus C) Alain Frisch
1999-10-12 15:32                       ` David Monniaux
1999-10-12 15:42                         ` Alain Frisch
1999-10-11 19:32                   ` speed versus C John Prevost
1999-10-11 20:50                 ` Gerd Stolpmann
1999-10-12 20:07                   ` skaller
1999-10-08  9:56           ` Pierre Weis
1999-10-07 15:25     ` Markus Mottl
1999-10-07  6:56   ` skaller
1999-10-07 12:37     ` Xavier Urbain
1999-10-07 22:18     ` Gerd Stolpmann
1999-10-08 19:15       ` skaller
1999-10-08 13:40   ` Anton Moscal
1999-10-06  7:58 ` Reply to: " Jens Olsson
1999-10-07 13:00 STARYNKEVITCH Basile
1999-10-08  6:57 Pascal Brisset
     [not found] <Pine.LNX.4.03.9910081713230.31666-100001@post.tepkom.ru>
1999-10-10  4:51 ` skaller
1999-10-11  9:08   ` Anton Moscal
1999-10-12 13:21 Damien Doligez
1999-10-12 20:42 ` 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=99100522193302.17263@ice \
    --to=gerd.stolpmann@darmstadt.netsurf.de \
    --cc=caml-list@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