Thanks Brad, I forgot about your version of it when I was packaging up the source. I'm currently incorporating everyone's optimizations and adding some new ones into a new version of Schemeray (as well as porting it to Scheme48, and working with Guillaume on the Jazz version). Where did you upload your newest version? I can't find it on the wiki site.
On Mar 21, 2008, at 3:25 PM, Bradley Lucier wrote:
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.