Updated Schemeray - Gambit-list

21 Mar 2008


      I'd found Schemeray by James Long on the net earlier, and had played  
around with it somewhat to get it to run a bit faster.  I've uploaded  
Schemeray-0.2b.tgz (think of "b" as the second version of 0.2, or for  
"Brad", however you like); here are the times on my 2.0GHz G5 with a  
100MB minimum heap ("gsi -:m100000")
Original:
(time (load "schemeray"))
     75190 ms real time
     73757 ms cpu time (72821 user, 936 system)
     1041 collections accounting for 33949 ms real time (33087 user,  
297 system)
     80379235552 bytes allocated
     no minor faults
     no major faults
"/Users/lucier/Desktop/Downloads/schemeray-0.2/schemeray.o2"
After playing around with inlining-limit and using flonum- and fixnum- 
specific operations:
(time (load "schemeray.o7"))
     20978 ms real time
     20870 ms cpu time (20672 user, 198 system)
     333 collections accounting for 4864 ms real time (4804 user, 48  
system)
     29847131896 bytes allocated
     no minor faults
     no major faults
"/Users/lucier/Desktop/Downloads/schemeray-0.3/schemeray.o7"
After changing the code to just write each pixel as it's computed,  
instead of saving them in a list and writing them all at the end of  
the computation:
(time (load "schemeray"))
     16775 ms real time
     16514 ms cpu time (16122 user, 392 system)
     284 collections accounting for 312 ms real time (306 user, 7  
system)
     29252226080 bytes allocated
     no minor faults
     no major faults
"/Users/lucier/Desktop/Downloads/schemeray-0.3/schemeray.o12"
A generational garbage collector would really have helped the second  
version of the code, and the third wouldn't have been necessary.
I'll let James decide what he wants to do with it.
Brad
PS:  One pixel in the image differs in one RGB component by 1; so the  
images are not identical, but I think that can be explained by  
rearrangement of some of the operations and round-off error.