|I get about 10s on my machine with the .NET version -- have not tested the others, but 40 seconds seems way too long. I've actually written a ray tracer in C# before, and it could render images very quickly (it included advanced features like transparency as well). There is definitely something wrong.
I see a bunch of odd things that could be making this much less efficient than it could be:
* Color should probably be a struct instead of class (but measure and find out)
* The stopwatch class uses DateTime, which is really, really bad for measuring small amounts of time. It's slow and inprecise for this usage. Use System.Diagnostics.Stopwatch instead.
* Outputting to the console is slow -- even at once per row, it might be enough to skew the timing.
** Related: calling String.Format is expensive. Might not matter for this application.
* Profiling this shows that the most expensive method is Sphere.Intersect. I suspect it's just the math and the fact that you're calling it so much.
* You can optimize the Sphere.Intersect method a bit more. You can store a precalculated radiusSquared value. You can put off the call to Math.Sqrt by squaring both sides of the equation and still checking against 0. You only need to cal Sqrt when distance > 0.
* a bunch of foreach statements. In many cases, these can be transformed into for-loops by the JIT, but not always. Enumerator.MoveNext is showing up in the profile, so consider changing these.
Lastly, what is the CPU usage like during each version of the program? Could other versions be automatically parallelizing some of the loops? Seems like a long shot, but I don't know.
And yeah, I know it's an obvious plug, but I've written an entire book on .NET performance. See my signature. It can teach you a bunch of stuff like the above, but more importantly, how to measure and diagnose these problems.
modified 4-Sep-14 12:23pm.