caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
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


  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).