Jon Harrop wrote:
[EMAIL PROTECTED] wrote:
For the interested, with MMA 6, on a Pentium 4 3.8Ghz:
The code that Jon posted:
Timing[Export["image-jon.pgm", [EMAIL PROTECTED]@Main[2, 100, 4]]]
{80.565, "image-jon.pgm"}
That is not the code I posted: you are using Xah's parameters that generate
a different (and largely empty) scene.
The code that Xah posted:
Timing[Export["image-xah.pgm", [EMAIL PROTECTED]@Main[2, 100, 4.]]]
{42.3186, "image-xah.pgm"}
So Xah's code is about twice as fast as Jon's code, on my computer.
The resulting files were identical (and both looked like pure white
images; I thought they'd be interesting!).
Use 9, 512, 4 instead of 2, 100, 4 and you will get a more interesting image
of over 80,000 spheres with shadows and diffuse lighting.
This is a really important difference: half of that program is dedicated to
hierarchical spherical bounding volumes that are essential when tracing a
large number of spheres. Xah solved a completely different problem by
simplifying the scene to only 5 spheres, where bounding volumes are useless
and the performance characteristics of the program are wildly different.
Lest anyone doubt that problem size is important for comparing program
run times, consider the following realistic example: the run time of
algorithm A is n*n, that of B is 10.6666666667*n*log2(n). A is faster
for small problems, B for large problems, with the crossover at 64. A
hybrid algorithm C could use B for large problems and A for small
problems and small subproblems generated by B's divide and conquer
technique. Python's list.sort is such a hybrid of binary insertion sort
and merge sort, with a crossover at 64 based on experimental data.
tjr
--
http://mail.python.org/mailman/listinfo/python-list
