Tuesday, February 21, 2006

"Kombilo Killer" progress

The meds today appear to have excessive alliteration + smilies as a side effect :)

"Project Kombilo" is at a crucial crossroads - the data-generation code is done, the pre-processing code has been written and passed the initial tests, and now I'm about to write the search code.

Without optimizations, I expect it to be quite fast, but of course this has to be proven first. And in the meantime, I feel apprehensive as if about to leave for my first date. If the code performs as well as I hope it will, the rush will be comparable to one's first real kiss.

The code is very elegant. It's small. The search algorithm has many avenues open for optimization, and I am pretty sure that I will build a kickass free-pattern search monster - but it will take a little more time. Yesterday I reached an impasse: I realized that my rather exotic design required the copying of 1.7 MB of state per searched game. I felt like the boy who finally got her out of her panties, only to realize he forgot the condoms - and, without them, no business.

I did what I always do in such a case: I took a bath (without design bottlenecks I might have succumbed to scabies already :). This stimulates the blood circulation to the brain, relaxes the mind, and resulted in the required Eureka-event, the "Aha Erlebnis", so to speak, the profound realization that my ass was saved if I only added one extra level of indirection. With the current financial crisis, I'm more worried I'll end up in an appartment without a bath, than that they'll steal my sources because in spite of profuse documentation and following all the rules of the trade, even I don't understand my code :)

Most of my "cool" code is complex array processing, using an 4-dimensional array architecture unfolded into a one-dimensional array, for example. I never architect code without thoroughly considering the underlying machine architecture. Example: The Kombilo module needs to reset a large array of counters for each examined game. I use a single byte for each counter, so that I can reset them using a 64-bit memory fill routine. If I were to put them in ordinary integers and use a loop to initialize them, this would take at least ten, but most likely twenty times longer. I think there is absolutely no hope for a programmer to engage in long-term competitive Go-related software development if he isn't intimately aquainted with the hardware. Example: The data structures my "statistical" pattern search module manipulates are aligned on a cache line. If I don't do that, the slowdown of that code is fifteen-fold. The lazy programmer hopes that his compiler will magically do those things for him :)

Please don't take my "Kombilo Killer" as derogatory to Kombilo: As a tribute to Ulrich Goertz, I chistened the unit file ZH_Kombilo, ZH for ZenHacker (all MoyoGo's unit files have this legacy prefix). The class is called TKombilo as well. Kombilo has been "doing its thang" for ages, my design has yet to prove itself..

But I like the competitive aspect of software development. Just like topsport, but on a comfortable chair with a beer :)

Beer is great to get implementation ideas, but don't drink more than half a litre when you're coding :)