[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