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
----------------------------------------------------------------------------
next prev 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