From: John Carr <jfc@MIT.EDU>
To: caml-list@inria.fr
Subject: Re: [Caml-list] NBody (one more question)
Date: Fri, 25 Feb 2005 12:06:52 -0500 [thread overview]
Message-ID: <200502251706.j1PH6qci027710@mass-toolpike.mit.edu> (raw)
In-Reply-To: Your message of "Thu, 24 Feb 2005 23:18:55 +0100." <20050224.231855.40627447.debian00@tiscali.be>
> When I compile the C code with -O0 (with gcc -o nbody.gcc -Wall
> --fast-math nbody.c -lm), I get a time of 1.513s which is comparable
> to OCaml (1.607s). But as soon as I turn on -O options (as with gcc
> -o nbody.gcc -Wall -O1 --fast-math nbody.c -lm), the running time
> drops down to 0.871s (0.58%). Can somebody tell me what is the
> optimization that has such an effect and whether it could be applied
> to OCaml ?
gcc -O0 sets out to generate the worst possible code, and mostly
succeeds. Optimizations in gcc -O1 compared to gcc -O0 include
register allocation, dead code elimination, branch straightening,
common subexpression elimination, instruction combining, and
instruction scheduling.
ocamlopt-generated code is between -O0 and -O1 in quality, usually
much closer to -O1. The biggest missing optimization is common
subexpression elimination. ocamlopt puts less effort into instruction
combining than gcc.
gcc -O2 adds loop optimizations which ocamlopt never does.
A functional programming style puts different demands on the
optimizer. ocamlopt has some optimizations that don't make
sense for C, e.g. replacing (unbox (box (value))) with value.
next prev parent reply other threads:[~2005-02-25 17:07 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-07 18:57 [Benchmark] NBody Christophe TROESTLER
2005-02-07 19:16 ` [Caml-list] " Will M. Farr
2005-02-07 19:36 ` Christophe TROESTLER
2005-02-07 19:55 ` Will M. Farr
2005-02-08 10:34 ` Olivier Andrieu
2005-02-08 10:52 ` Micha
2005-02-07 20:16 ` Markus Mottl
2005-02-07 19:37 ` Martin Jambon
2005-02-07 19:46 ` Christophe TROESTLER
2005-02-07 20:22 ` Martin Jambon
2005-02-07 20:04 ` sejourne_kevin
2005-02-07 20:32 ` Robert Roessler
2005-02-07 22:57 ` Oliver Bandel
2005-02-08 1:29 ` skaller
2005-02-08 1:48 ` Will M. Farr
2005-02-08 9:01 ` Ville-Pertti Keinonen
2005-02-08 9:37 ` skaller
2005-02-08 10:10 ` Ville-Pertti Keinonen
2005-02-08 16:36 ` skaller
2005-02-08 12:04 ` Marcin 'Qrczak' Kowalczyk
2005-02-08 17:06 ` skaller
2005-02-08 10:25 ` Xavier Leroy
2005-02-08 18:34 ` skaller
2005-02-08 10:43 ` Xavier Leroy
2005-02-08 11:26 ` Ville-Pertti Keinonen
2005-02-08 15:59 ` Florian Hars
2005-02-13 16:40 ` Christoph Bauer
2005-02-13 18:13 ` Christophe TROESTLER
2005-02-24 22:18 ` NBody (one more question) Christophe TROESTLER
2005-02-25 17:06 ` John Carr [this message]
2005-02-25 17:17 ` [Caml-list] " Christophe TROESTLER
2005-02-26 16:08 ` John Carr
2005-02-25 17:24 ` Ken Rose
2005-02-25 17:42 ` Oliver Bandel
2005-02-25 17:57 ` Xavier Leroy
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=200502251706.j1PH6qci027710@mass-toolpike.mit.edu \
--to=jfc@mit.edu \
--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