You would definately need something domain specific to help with any serious optimization, and even that probably wouldnt be enough. For example, in the simple case you would perform everything in high precision floating point, or even better as much precision as you need, but often you have to compromise and drop precision in favour of speed, and that requires some interaction with your black box optimizer to tell it what it can get away with.

The frustrating part is the amount of time that we have to devote to plumbing and wiring and jury rigging the elegant solutions we enjoy spending our time devising. I’ll buy you a pint when you’ve found the solution.
Craig

When I read this article, I was reminded of the idea of proving the correctness of programs. Bear with me for an analogy.

When I was studying, there was this idea that a program might come with a proof that it accorded to some specification. The developer enviroment would have tools that helped you derive a program from the specification in a way that guaranteed that it met that spec. Of course this can be done for toy programs. The hope was that approaches could be found that would scale well enough to help in the real world.

For the most part, this dream has not been realised. Formalising specifications is hard! Formalising proof/derivation techniques is harder, and it always misses some of the ever expanding set of tricks you want to use. I’m sure progress continues to be made in these areas, but it hasn’t touched my daily developer life since I left academia.

So back in the real world, we get value from using unit tests instead. It’s one tenable way of kinda formalising specifications, because programming languages are pretty good ways to describe the behaviour of programs. And although running lots of test cases doesn’t guarantee program correctness, it’s a significant confidence boost. You haven’t shown the program will always do the right thing, but you have definitely shown it does the right thing in lots of important cases. (Quasi)Proof by example.

By now the analogy should be obvious. (If you prefer, it’s not even an analogy, just a specialization of the above to a particular kind of spec/test.) Yes, it would be wonderful to formalise a framework wherein one could apply all the useful transformations to turn nice programs into fast programs and therefore know that these two programs - the one you understand and the one you run - were intensionally equivalent. Nice research project. May pay off big one day.

In the mean time, here we are in that real world again. So: write the nice program. Derive the fast program yourself, by hand, using all your cleverness. Then offer evidence that they are extensionally equivalent: make sure they give appropriately equal results when run on a battery of test-cases.

(I know I’m not saying you anything you don’t already know, Andy, since you implemented various clean reference renderers to test for equivalence with the quick-but-dirty tweaked to SSE hell released versions at Voxar. But I thought it might be worth saying it out loud nonetheless.)

The data structure issue isn’t so relevant in, say, volume rendering, but it’s a potentially huge win if you have something more complex. Debugging the optimized code and data structures would be “interesting”.

I think I need more knowledge of graph theory…

Graph theory: yeah, I always resent when one of my real-world interests drives me to learn about some dry, abstract area like graph theory. But it’s happening more and more. Automated proof systems is the other thing which I keep getting dragged reluctantly towards.

You can claim your beer next time you’re in Edinburgh.