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] 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


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