[gambit-list] number->integer

Bradley Lucier lucier at math.purdue.edu
Thu Oct 30 13:24:57 EDT 2008


On Oct 30, 2008, at 12:04 PM, Bradley Lucier wrote:

> [descartes:~/Desktop] lucier% gsi -:m100000
> Gambit v4.3.0
>
> > (load "fix")
> "/Users/lucier/Desktop/fix.o2"
> > (time (test1 1000000 0.2))
> (time (test1 1000000 .2))
>    1453 ms real time
>    1437 ms cpu time (1237 user, 200 system)
>    3 collections accounting for 3 ms real time (3 user, 0 system)
>    400000000 bytes allocated
>    no minor faults
>    no major faults
> > (time (test0 1000000 0.2))
> (time (test0 1000000 .2))
>    1372 ms real time
>    1363 ms cpu time (1346 user, 17 system)
>    12 collections accounting for 11 ms real time (11 user, 0 system)
>    1232138320 bytes allocated
>    no minor faults
>    no major faults
> >
>
> It appears that once one defines a large enough minimum heap size to  
> basically remove gc time, the largest time hog is the intermodule  
> calls and returns for inexact->exact and truncate.  You can see that  
> working with rational numbers adds a lot to the heap allocation.

And yet, with a slightly different argument, f0 is decidedly faster:

> [descartes:~/Desktop] lucier% gsi -:m100000
> Gambit v4.3.0
>
> > (load "fix")
> "/Users/lucier/Desktop/fix.o4"
> > (time (test1 1000000 12.2))
> (time (test1 1000000 12.2))
>     1361 ms real time
>     1352 ms cpu time (1156 user, 196 system)
>     3 collections accounting for 3 ms real time (3 user, 0 system)
>     400000000 bytes allocated
>     no minor faults
>     no major faults
> > (time (test0 1000000 12.2))
> (time (test0 1000000 12.2))
>     990 ms real time
>     983 ms cpu time (970 user, 13 system)
>     4 collections accounting for 4 ms real time (4 user, 0 system)
>     384000000 bytes allocated
>     no minor faults
>     no major faults

This is reproducible. Something strange is going on, I agree.

Brad




More information about the Gambit-list mailing list