Mathematica 7 compares to other languages
Terry Reedy
tjreedy at udel.edu
Mon Dec 8 20:25:35 EST 2008
Jon Harrop wrote:
> jason-sage at creativetrax.com wrote:
>> For the interested, with MMA 6, on a Pentium 4 3.8Ghz:
>>
>> The code that Jon posted:
>>
>> Timing[Export["image-jon.pgm", Graphics at Raster@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", Graphics at Raster@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
More information about the Python-list
mailing list