[gambit-list] Updated Schemeray
James Long
longster at gmail.com
Sat Mar 22 18:54:26 EDT 2008
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.
More information about the Gambit-list
mailing list