Tim Bray wrote:
> The conclusion of this lengthy and interesting thread is obvious: the
> original claim, "For performance, write it in C", has been convincingly
> debunked.
>
> Along with all the other conventional wisdom about premature
> optimization and profiling and 80/20 points, we have seen it
> demonstrated that several other languages, of many different types, can
> come so close to C's performance that it's difficult to measure the
> difference.
>
> The *real* lesson is: Achieving good performance is hard; it requires
> analysis and experimentation, and any simple prescription (e.g. "Use
> programming language X") is dangerously misleading.
>
> And finally: In the real world, the only benchmark that matters is your
> application.
>
>    -Tim

I'll accept your *real* lesson, and add one more ;-)

Although "out of the box thinking" is a sickening cliche, our thinking
does often get stuck in box. In this case, we're stuck in a box
exhaustively generating latin squares.

Once we loosen some constraints and push back the problem boundaries,
maybe we'll see that there are so many latin squares for 9x9 that they
might as well be infinite.

Maybe we'll remember that we have techniques for dealing with infinite
sequences - lazy evaluation, streams, generators... let's assume that
we have a 9x9 lazy latin square generator that we can pause and resume.
Then the interesting question is how do we write generators that
produce different traversals - random traversal, lexicographic
traversal, ...

Now the performance question has changed - are the latin squares
streams being consumed faster than the squares are generated, or is the
bottleneck somewhere else?

Man, that "out of the box thinking" is scary stuff ! :-)