Clean Code is Just Better

One thing that I've found time and time again in my coding career is that leads to a virtuous cycle of improvements. It's easier to read. It's easier to understand. It's easier to change. It's shorter. It simpler. It often even runs a fair bit faster. Expressing an idea in code more cleanly and clearly to both human readers and the compiler reaps many benefits.

Now, all this is frankly stating the bleeding obvious. Although, in this case, it had an interesting outcome: Cleaning up my Haskell raytracer code and fixing all the -Wall errors more than doubled its performance. It's now down from 3.5 minutes to 1.5 minutes.

Now, fixing up a few warnings in a lower-level language like C++ typically provides small execution time benefits or prevents future portability or correctness problems. But it just shows what a dramatic effect fixing warnings has in a higher level language. In such a language, a confused compiler can end up doing some very expensive things. From a performance perspective, you're not just blowing off your own foot, you're nuking the whole town.

Most of the issues I fixed were simple things like incomplete pattern matches, mixtures of ^ and ** and confusion over what return type to use for calls to things like round or truncate.

So, 90 seconds to raytrace a simple scene still isn't going to set SIGGRAPH alight, but it's beginning to get into the right sort of ballpark. This kind of win has provided evidence for my suspicion that the code was basically reasonable but something bad was going on under the hood. Just looking an the intermediate .hc files, I can see there is still a lot more time to be won back..