From: Jon Harrop <jon@ffconsultancy.com>
To: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Multiplication of matrix in C and OCaml
Date: Sat, 10 Feb 2007 16:11:06 +0000 [thread overview]
Message-ID: <200702101611.06265.jon@ffconsultancy.com> (raw)
In-Reply-To: <n98xf6j9ic.fsf@hod.lan.m-e-leypold.de>
On Saturday 10 February 2007 15:51, ls-ocaml-developer-2006@m-e-leypold.de
wrote:
> Damn. I should have taken '+'.
Even for modulo integer arithmetic that still breaks:
a+b > a+c
when a+c wraps around max_int and becomes negative but a+b does not, then
a+b>a+c even though c>b.
> Is the compiler allowed to make optimizations according to known
> mathematical laws?
Provided they are the correct laws, yes.
> I've been wondering about similar optimizations for floats, but didn't
> get my examples right. The transformtion done by the compiler would of
> course be forbidden to increase the error.
Yes, which is actually very restrictive. That is why -ffast-math can make
C/C++ programs run so much more quickly. In OCaml, -ffast-math has a
different purpose (to enable the emission of trig instructions, IIRC) and it
exists on x86 and not AMD64 whereas the same flag exists on both platforms
for GCC.
Incidentally, why is -ffast-math not always enabled on x86 and why isn't it a
no-op on AMD64 (rather than causing an "unknown option" error as it does
ATM)?
> Still: With a certain Gcc version and flags combination the OP saw a
> threefold improvement in performance. That in intself is suspicious (I
> don't think that this much optimization potential was left in Gcc ...)
> and I still would check for optimization errors in this case. Gcc is
> not bug free either, so one should test the correctness of the
> compiled program first and wether it really does the work it is
> supposed to do.
Although Frederic is an expert OCaml programmer, it sounds like his C was a
little off the mark (having undefined behaviour and allowing arbitrary
optimisations as a consequence).
Benchmarking is a real can of worms. I've spent a long time trying to
benchmark programs and languages and I really think the only feasible way
forward is to measure the real time taken to solve real problems.
Even this quickly becomes apples and oranges. For example, F# has a concurrent
GC and I have a dual core machine, so F# has the advantage that even single
threaded programs can exploit both cores when they are allocation intensive.
So how am I supposed to compare the performance of the two languages? There is
no panacea. In the end I must measure the time taken to perform an important
real world task, like spinning a 3D bunny around. Is spinning a bunny serious
enough though? If not, maybe I should use a Mandelbrot renderer:
http://caml.inria.fr/cgi-bin/hump.en.cgi?contrib=481
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists
next prev parent reply other threads:[~2007-02-10 16:18 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-07 23:42 Frédéric Gava
2007-02-08 2:14 ` [Caml-list] " Jacques Garrigue
2007-02-08 9:27 ` Frédéric Gava
2007-02-08 9:38 ` Frédéric Gava
2007-02-08 12:08 ` Jacques Garrigue
2007-02-08 9:56 ` Frédéric Gava
2007-02-08 10:45 ` Xavier Leroy
2007-02-08 15:16 ` Frédéric Gava
2007-02-09 2:58 ` Jacques Garrigue
2007-02-09 9:06 ` ls-ocaml-developer-2006
2007-02-09 10:32 ` ls-ocaml-developer-2006
2007-02-09 14:22 ` skaller
2007-02-09 21:47 ` ls-ocaml-developer-2006
2007-02-09 21:55 ` Andrej Bauer
2007-02-09 22:36 ` ls-ocaml-developer-2006
2007-02-09 23:53 ` Jon Harrop
2007-02-10 1:41 ` ls-ocaml-developer-2006
2007-02-10 2:24 ` Jon Harrop
2007-02-10 14:41 ` ls-ocaml-developer-2006
2007-02-10 14:52 ` Jon Harrop
2007-02-10 15:51 ` ls-ocaml-developer-2006
2007-02-10 16:10 ` Xavier Leroy
2007-02-10 16:11 ` Jon Harrop [this message]
2007-02-10 14:55 ` Mattias Engdegård
2007-02-11 13:13 ` Christophe Raffalli
2007-02-10 1:10 ` Brian Hurt
2007-02-10 1:16 ` Robert Roessler
2007-02-09 23:56 ` Jon Harrop
2007-02-09 12:05 ` Jon Harrop
2007-02-09 12:35 ` ls-ocaml-developer-2006
2007-02-09 13:50 ` Brian Hurt
2007-02-09 14:23 ` Gerd Stolpmann
2007-02-09 14:24 Frederic GAVA
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=200702101611.06265.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