caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Brian Hurt <bhurt@spnz.org>
To: John Hughes <jfh@cs.brown.edu>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] More or bignums/ints
Date: Mon, 14 Jun 2004 10:37:29 -0500 (CDT)	[thread overview]
Message-ID: <Pine.LNX.4.44.0406141019580.4243-100000@localhost.localdomain> (raw)
In-Reply-To: <20040611193818.0A43457251@twix.cs.brown.edu>

On Fri, 11 Jun 2004, John Hughes wrote:

> I've read the May interchange in CWN that started with the question
> 
> > I have made a web search to understand which kind of support for 
> > bignums is available for OCaml...
> 
> and found it interesting. I'll be teaching a few weeks of ML as part 
> of a first-year course at Brown University, and we've used SML in 
> previous years. SML/NJ works OK, but we'd like a debugger, so I've 
> looked at OCaml as a possible alternative. I was a little depressed 
> to find (by trial and error) that "int" doesn't mean "integer" but 
> rather "element of Z/nZ for some very large n, represented with 
> integer notation, including negative signs." 

Yep.  Generally mod 2^n for some n.  This is because this is what the 
hardware supplies for fast integer arithemetic.  "Fixing" this, so that 
ints are real (mathematical) integers entails a *huge* performance cost, 
for very little gain.

> 
> I think I can live with this if only there's some way to write 
> something like this (pseudo-ML/Java):
> 
> fun fact(0) = 1
>   | fact(n) = try {
>                  n * fact(n-1)
>               }
>               catch (IntegerOverflow e) ...
> 

There are two problems with this: 1) most CPUs don't support throwing 
exceptions on integer overflows, because 2) the CPU throwing an exception 
is incredibly expensive (two complete pipeline drains (the same cost as a 
mispredicted branch), and two task switches (into and back out of the 
OS)).  

You might be able to modify the ocaml compiler to add overflow checking 
code.  Most CPUs have a "jump on overflow" instruction.  But currently, an 
integer add takes at most 2 instructions (the second instruction to deal 
with the tag bit), and often only one.  This change would cause an add 
instruction to take at least two, maybe three, instructons- for a 
signifigant performance hit (this is assuming that the throwing the 
exception code is factored out).

How big of a performance hit, I don't know.  I note that on the Great 
Language Shootout page, SML/NJ has a much lower performance score than 
Ocaml or MLton.

Note that the numeric people have exactly the same problem, and are more 
likely to hit it than your average code.

> 
> What I don't think I can bear is to use the sorts of "bignum"-like 
> libraries that make me write things like
> 
>  y = x bigadd big-unit
> 
> to mean 
> 
>  y = x + 1
> 
> because our students will actually be writing some code that has 
> a good deal of arithmetic in it. 

Define new operators.

-- 
"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
                                - Gene Spafford 
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


  parent reply	other threads:[~2004-06-14 15:31 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-11 19:38 John Hughes
2004-06-12  0:09 ` Jacques Garrigue
2004-06-14 15:37 ` Brian Hurt [this message]
2004-06-14 16:17   ` Andreas Rossberg
2004-06-14 15:55 ` Xavier Leroy
2004-06-15 22:45   ` Manos Renieris
2004-06-15 20:26 ` Brian Hurt
2004-06-15 20:36   ` Brian Hurt
2004-06-23 10:50   ` John Hughes
2004-06-23 14:51     ` skaller

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.44.0406141019580.4243-100000@localhost.localdomain \
    --to=bhurt@spnz.org \
    --cc=caml-list@inria.fr \
    --cc=jfh@cs.brown.edu \
    /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).