[MLton] Int Overflow detection

[Neophytos Michael]

I agree it may not be a typical SML program but that's what I use SML for and
that's why I am interested in how mlton performs for such programs.  Let me
just say that my intention here is not to criticize the compiler or its
developers but to point out deficiencies and help in my small way in improving
mlton.  The number of man hours spent on gcc is orders of magnitudes that what
has been spent on mlton and what you have achieved here with your limited
resources is nothing short of amazing.  Mlton's existance is the reason I still
program in SML.

Now as to your criticism on how atypical this program is in the SML world that
may be true.  But I think the "problems" it exposes could help the typical SML
program as well.  All programs have loops, and most computation time is spent
in loops.  In SML people don't see them as much since they are hidden behind
our folds, and maps but they are there.  So for instance a transformation like:

while(cond) { body; }  ==> if (! cond) goto get_out;
                           do { body; } while ( cond; }

will help the typical SML program as much my pseudo benchmark.  The same is
true with move loop invariant computations out of loops.  And given the high
tech representations that mlton has perhaps some of these optimizations would
not be incredibly difficult to implement.

Anyway here are some numbers for the pseudo benchmark.  I changed the program a
bit so as not to overwhelm my small machine.  So I now create a large array of
reals and add the elements of that array several times accumulating the sum.  I
implemented the same program in C.  I tried to make the test as fair as
possible  -- if I pessimised one against the other it was not intentional.  I
timed both programs with time under cygwin.  The running times are:

C Program running times:
------------------------
real    0m2.122s
user    0m2.421s
sys     0m0.015s

mlton Program running times:
----------------------------
real    0m3.110s
user    0m3.436s
sys     0m0.077s

The C program was compiled as:
gcc -O3 -o b.exe b.c
and the mlton one:
mlton -const 'MLton.detectOverflow false' -output a.exe a.sml

both on cygwin.  gcc version 3.3.3 and MLton 20041109.

Both programs are included here.
-------------------------------------------------------------
static
double foo( double* a, int l )
{
  int i;
  double s = 0.0;

  for (i = 0; i < l; ++i)
    s += a[i];

  return s;
}

const int m = 100;
const int n = 7000000;

int main()
{
  double *a = malloc(n * sizeof(double));
  double sum = 0.0;
  int i;

  for (i = 0; i < n; ++i)
    a[i] = 0.1 + (i % 3) * 0.1;

  for (i = 0; i < m; ++i)
  {
    sum += foo(a, n);
  }
  printf("Length sum = %g\n", sum);

  return 0;
}
-------------------------------------------------------------
structure T : sig end =
struct
fun sum (a, l) =
  let
    fun sumloop (i, res) =
        if i = l then res
        else sumloop (i + 1, Unsafe.Array.sub (a, i) + res)
  in
    sumloop (0, 0.0)
  end

val n = 7000000
val ll =  Array.tabulate (n, fn i => 0.1 + Real.fromInt (i mod 3) * 0.1)

fun g m =
  let
    fun gloop (i, res) = if i = m then res
                         else gloop (i + 1, res + sum (ll, n))
  in
    gloop (0, 0.0)
  end

val m = 100

val () = (print "Length sum = ";
          print (Real.toString (g m));
          print "\n")
end
-------------------------------------------------------------

Neophytos


--- Matthew Fluet <fluet@cs.cornell.edu> wrote:
> 
> > I wanted to compare mlton's performance with gcc on this platform (cygwin,
> x86)
> > and wanted a fair test.  
> 
> The test is fair in the sense that it computes the same value, but unfair
> in the sense that this is not a typical SML program, nor a program that is
> susceptible to the kinds of optimizations towards which MLton has invested 
> time and effort.
> 
> > I am only showing the main loop here (this is with int overflow turned
> off). 
> > So it's 4 instructions for gcc versus 9 for mlton.
> 
> I doubt this has any significant affect on run-time performance.
> 
> > I have not timed the loops.  If there is interest I could do that.
> 
> I think that would be more instructive than counting instructions.
> 
> _______________________________________________
> MLton mailing list
> MLton@mlton.org
> http://mlton.org/mailman/listinfo/mlton
> 


		
__________________________________ 
Do you Yahoo!? 
Make Yahoo! your home page 
http://www.yahoo.com/r/hs