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