Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: Xavier Leroy <Xavier.Leroy@inria.fr>
To: David McClain <dmcclain@azstarnet.com>, caml-list@inria.fr
Subject: Re: OCaml and C math routines
Date: Sat, 14 Oct 2000 14:19:15 +0200	[thread overview]
Message-ID: <20001014141915.60643@pauillac.inria.fr> (raw)
In-Reply-To: <003a01c03537$3e67fe50$210148bf@dylan>; from David McClain on Fri, Oct 13, 2000 at 10:01:33AM -0700

> OCaml'ers... I would be very interested to hear your response to this!

Here is a copy of the response I posted on comp.lang.ml:

Zhong Shao <shao@cs.yale.edu> writes:

> From what I know, for the floating-point intensive benchmarks, Ocaml
> is faster than SML/NJ mainly because Ocaml directly calls the native,
> C-based math library (which in turn is fine-tuned for the actual
> processor).  SML/NJ, on the other hand, implements all of the math
> library functions (e.g., cos, sin, tan) in ML itself (as part of the
> SML basis).

Thanks, Zhong, for this interesting piece of information.  I had no
idea that the SML Basis Library took such a "bare-bone" approach...

> Members of the SML basis committee and the Ocaml group probably can
> tell us the pros and cons of calling the native math library vs. having
> it written in ML itself.

Short answer: the idea of writing the math functions in ML itself
never even crossed my mind, and I can see absolutely no reason why one
would want to do so.

Longer answer: here are a bunch of reasons why calling the native math
library makes much more sense.

1- Availability: any Unix system, and any C compiler for other OS,
come with a math library conforming to ANSI (for the API) and IEEE
(for the semantics of the math operations).  So there are no
portability issues in using the native math library.

2- Correctness: floating-point arithmetic is surprisingly tricky.  These
native math libraries are widely used, in C and Fortran, by demanding
numerical users, so chances are that they are more correct than
anything we can write ourselves.  (And if they are not correct,
someone else gets to fix them, not us.)  Some of these libraries were
written by leading experts in the field (I'm thinking of Apple's SANE
library, which I believe was originally written by Prof. Kahan, one of
the biggest names in the area.)  So, I trust those libraries to be
more correct than anything I could write myself.

3- Speed: we can safely expect the native math library to be nearly
optimal in terms of performances, including processor-specific
optimizations, e.g. critical parts are written in assembly, exploiting
all resources of the target processor.  Sometimes, these libraries are
even written by the same people that designed the processor (I'm
thinking of Motorola's library for the Power PC).  So, I trust those
libraries to be faster than anything I could write myself.

4- Economy of means: implementors of ML have very limited human
resources, so it makes much more sense to interface with good existing
C libraries rather than redo everything from scratch.  In many areas,
it's not obvious to find good C libraries that do what we want, so
reimplementation in ML might be justified; but in the case of
floating-point math functions, I really don't see anything to hold
against the existing math libraries.  So, reimplementing exp() or sin()
myself would just be a waste of my time (and rather boring, in addition).

Now, I'd really love to hear from the SML Basis Library designers and
see what reason they can come up with to justify implementing the math
functions in ML.

- Xavier Leroy

-- 
Valid e-mail address (without the underscores): Xavier.Leroy@i_n_r_i_a.f_r
This is a protection against junk mail. Apologies for the inconvenience.
Home page: http://pauillac.inria.fr/~xleroy/



  reply	other threads:[~2000-10-14 12:40 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-10-13 17:01 David McClain
2000-10-14 12:19 ` Xavier Leroy [this message]
2000-10-13 22:17 John R Harrison
2000-10-16 12:55 Dave Berry

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=20001014141915.60643@pauillac.inria.fr \
    --to=xavier.leroy@inria.fr \
    --cc=caml-list@inria.fr \
    --cc=dmcclain@azstarnet.com \
    /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