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