From: Brian Hurt <brian.hurt@qlogic.com>
To: Nickolay Semyonov-Kolchin <snob@snob.spb.ru>
Cc: David Chase <chase@world.std.com>, <caml-list@inria.fr>
Subject: Re: Coyote Gulch test in Caml (was Re: [Caml-list] speed )
Date: Mon, 20 Jan 2003 18:54:08 -0600 (CST) [thread overview]
Message-ID: <Pine.LNX.4.33.0301201809120.2036-100000@eagle.ancor.com> (raw)
In-Reply-To: <200301210239.01608.snob@snob.spb.ru>
On Tue, 21 Jan 2003, Nickolay Semyonov-Kolchin wrote:
> On Tuesday 21 January 2003 02:23, David Chase wrote:
>
> Speed and accuracy are different things. Matlab class software need
> accuracy, most computer games need speed. This is the reason of
> "-ffast-math" key in gcc. Ocaml lacks such key, and always produce
> ineffecient floating-point code.
>
>From gcc's info:
`-ffast-math'
This option allows GCC to violate some ANSI or IEEE rules and/or
specifications in the interest of optimizing code for speed. For
example, it allows the compiler to assume arguments to the `sqrt'
function are non-negative numbers and that no floating-point values
are NaNs.
This option should never be turned on by any `-O' option since it
can result in incorrect output for programs which depend on an
exact implementation of IEEE or ANSI rules/specifications for math
functions.
Which raises a couple of questions. The first question is wether
-ffast-math mainly violates ANSI or IEEE rules. If ANSI, we're OK- we
just define the Ocaml rules so we don't have to violate them.
But then this brings up the issue of conformity vr.s performance. For
example- the x86 has its 80-bit FP registers in 8087-legacy mode, but
64-bit registers if you're using SSE2. And PowerPC and PA-RISC both have
extended precision fused multiply-adds (that keep higher precision, i.e.
don't round, between the multiply and the adds). For that matter, could a
"conforming" implementation of Ocaml use the 32-bit single precision SSE-1
registers?
http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf
http://www.cs.berkeley.edu/~wkahan/Curmudge.pdf
As a general rule, I perfer the higher precision when it doesn't hurt
enormously. Basically, keeping things at at least 64-bit IEEE FP is a
good idea- except in special cases, the speed advantage of going down to
single precision.
Oh, and if we're talking about performance, memory behavior is much more
important than precision of floating point primitives (so long as FP is in
hardware). A complex FP operation may take tens of clock cycles- but a
cache miss now takes hundreds. The most important paper about numeric
performance of Ocaml might be this one:
http://www.cs.princeton.edu/~mjrg/fpca95.ps.Z
Brian
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
next prev parent reply other threads:[~2003-01-21 0:45 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-03 16:00 [Caml-list] speed onlyclimb
2003-01-03 11:38 ` [Caml-list] speed Clemens Hintze
2003-01-03 11:47 ` [Caml-list] speed Noel Welsh
2003-01-02 16:45 ` Chet Murthy
2003-01-03 13:32 ` Xavier Leroy
2003-01-02 17:52 ` Chet Murthy
2003-01-03 14:53 ` Sven Luther
2003-01-03 15:28 ` Erol Akarsu
2003-01-02 17:53 ` Coyote Gulch test in Caml (was Re: [Caml-list] speed ) Chet Murthy
2003-01-03 15:10 ` Shawn Wagner
2003-01-03 15:56 ` Oleg
2003-01-04 18:31 ` Xavier Leroy
2003-01-18 22:49 ` Oleg
2003-01-18 23:50 ` Shawn Wagner
2003-01-20 21:23 ` David Chase
2003-01-20 21:39 ` Nickolay Semyonov-Kolchin
2003-01-21 0:54 ` Brian Hurt [this message]
2003-01-21 13:09 ` David Chase
2003-01-21 13:15 ` Daniel Andor
2003-01-21 20:26 ` Nickolay Semyonov-Kolchin
2003-01-19 10:33 ` Siegfried Gonzi
2003-01-19 10:34 ` Siegfried Gonzi
2003-01-21 9:56 ` [Caml-list] Re: Coyote Gulch test in Caml Xavier Leroy
2003-01-21 15:57 ` Brian Hurt
2003-01-27 16:58 ` Daniel Andor
2003-01-28 8:27 ` Christian Lindig
2003-01-05 1:13 ` [Caml-list] speed Brian Hurt
2003-01-05 1:48 ` Michael Vanier
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=Pine.LNX.4.33.0301201809120.2036-100000@eagle.ancor.com \
--to=brian.hurt@qlogic.com \
--cc=caml-list@inria.fr \
--cc=chase@world.std.com \
--cc=snob@snob.spb.ru \
/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).