CheckerBoard

Checkers Tutor for Android published!

2009-12-23T01:20:00.002+01:00

I finally got round to publishing my Android checkers program - it *should* be available on the Android market under the name "Checkers Tutor" - but since I don't have an Android phone I have no way of knowing whether it really is there!

Java checkers' first game

2009-03-06T23:06:00.005+01:00

My as yet unnamed Java checkers engine just played its first game against itself! Apparently, there is still some room for improvement...

[Event "Test"]
[Date "3rd March 2009"]
[Black "Java Engine"]
[White "Java Engine"]
[Result "1/2-1/2"]
1. 11-15 22-18 2. 15x22 25x18 3. 8-11 29-25 4. 12-16 25-22 5. 16-20 24-19 6. 9-13 19-16 7. 5-9 28-24 8. 10-15 16-12 9. 6-10 23-19 10. 11-16 18x11 11. 16x23 27x18 12. 20x27 32x23 13. 7x16 22-17 14. 13x22 26x17 15. 9-13 30-26 16. 13x22 26x17 17. 16-20 31-27 18. 4-8 23-19 19. 8-11 17-13 20. 11-16 27-23 21. 20-24 18-14 22. 10x17 21x14 23. 24-27 19-15 24. 27-31 15-11 25. 31-26 23-18 26. 16-20 11-8 27. 26-22 18-15 28. 22-17 15-10 29. 20-24 8-4 30. 2-6 10-7 31. 17x10 7-2 32. 24-28 2x9 33. 1-5 4-8 34. 5x14 13-9 35. 28-32 9-5 36. 10-15 5-1 37. 14-18 8-4 38. 18-23 1-6 39. 23-27 6-2 40. 27-31 2-6 41. 15-11 6-2 42. 31-26 2-6 43. 32-28 6-2 44. 26-23 2-6 45. 23-26 6-2 46. 26-23 2-6 47. 23-26 6-2 48. 26-23 2-6 49. 23-26 6-2 50. 26-23 2-6

and a draw by repetition because it doesn't yet understand the concept of progress...

Java checkers' first sensible game

2009-03-08T21:56:00.004+01:00

After improving the evaluation function a bit and after adding some standard search improvements, my Java checkers engine now appears to be playing a good game. It searches 3 million positions per second on my 2GHz Core Duo laptop, and typically gets around 17 ply search depth within a few seconds (that is faster than simple checkers, and a few ply deeper than simple checkers). It can't use endgame databases (yet?!) and has no opening book, but apart from that it is "Cake light" - a simplified version of Cake, using parts of the evaluation and parts of the search strategies that Cake does - but all on a much less complex level. The code is a joy to read compared to the Cake source code :-) (and much shorter). I will still have to improve the "Javaness" of the code - coming from a procedural language, I am writing C-style code in Java...

Here is the first sensible game of the engine playing against itself - red got a winning position but then blew it. But at least this already looks like checkers to me.

[Event "test game"]
[Date "2009-03-08"]
[Black "Java Engine"]
[White "Java Engine"]
[Result "1/2-1/2"]
1. 11-15 22-18 2. 15x22 25x18 3. 8-11 29-25 4. 4-8 25-22 5. 11-16 23-19 6. 16x23 26x19 7. 9-14 18x9 8. 5x14 27-23 9. 8-11 22-18 10. 14-17 21x14 11. 10x17 24-20 12. 17-22 32-27 13. 1-5 30-26 14. 6-10 26x17 15. 10-15 19x10 16. 7x21 23-19 17. 2-7 27-24 18. 21-25 19-16 19. 12x19 24x8 20. 3x12 18-14 21. 25-30 28-24 22. 30-25 31-26 23. 25-21 26-22 24. 21-25 22-18 25. 25-22 18-15 26. 22-26 15-10 27. 5-9 10x3 28. 9x18 24-19 29. 18-22 3-7

Java perft, again

2009-03-10T19:05:00.004+01:00

After some more optimizations my Java perft now runs much faster than before, it is now nearly half as fast as the C code. I would have expected much less from Java and am pleasantly surprised. I'm quite happy already with the Java engine, so now for the hard part - creating an interface....

perft 1 time 1 positions 7 kN/s 7
perft 2 time 1 positions 49 kN/s 49
perft 3 time 1 positions 302 kN/s 302
perft 4 time 1 positions 1469 kN/s 1469
perft 5 time 1 positions 7361 kN/s 7361
perft 6 time 15 positions 36768 kN/s 2451
perft 7 time 1 positions 179740 kN/s 179740
perft 8 time 63 positions 845931 kN/s 13427
perft 9 time 250 positions 3963680 kN/s 15854
perft 10 time 1156 positions 18391564 kN/s 15909
perft 11 time 5437 positions 85242128 kN/s 15678
perft 12 time 24954 positions 388623673 kN/s 15573

Multi-core KingsRow tested

2009-07-15T22:45:00.007+02:00

I have been testing KingsRow 1.16d against Cake 1.8x12 on my quadcore machine. Here are some results of engine matches at 5 seconds per move:


Cake 1.8x12 - KingsRow 1.16d (1 core)  +19 -14 =255
Cake 1.8x12 - KingsRow 1.16d (2 cores) +19 -18 =251
Cake 1.8x12 - KingsRow 1.16d (4 cores) +18 -19 =251

I had been expecting Cake to be slaughtered by the multi-core version of KingsRow, but apparently it's not that bad. To check whether or not it might be a bug in the multithreaded search of KingsRow, I played a match with Cake and KingsRow running on 1 core, but KingsRow got 10 seconds per move - so essentially this should reproduce the second match above. I found


Cake 1.8x12 - KingsRow 1.16d (10s)  +17 -21 =250

There is always some variability in engine matches, otherwise one might conclude that the 2-core version of KingsRow was not performing as well as KingsRow with twice the search time. As it is, I don't quite know what to make of it.

CB and Windows 7

2009-12-16T21:46:00.003+01:00

I'm writing this post on my brand-new Windows 7. Unlike Vista to which I took an instant dislike, this product seems to be much more user-friendly (UAC...) and the harddisk isn't working for about an hour after startup. Of course, the very first thing I did with Win7 was to test whether CheckerBoard was working on it, and it is - however, it has to be run as Administrator, otherwise it crashes. I think it was the same with Windows Vista (but I can't remember), and I hope I will have some time during the christmas holidays to sort out these issues.

KingsRow goes multicore!

2009-07-14T15:19:00.003+02:00

The amazing Ed Gilbert has done it again: he rewrote his KingsRow engine so that it can use multiple CPUs. While he was at it, he also fixed a few bugs in CheckerBoard. You can download a new version of CheckerBoard, and the multi-CPU-KingsRow on Ed's webpage. Enjoy!

Java checkers' first draw against Cake

2009-03-18T22:48:00.003+01:00

My Java checkers engine now has its own - very primitive - GUI based on Swing, and I can let it play games against my other engines. Here is its first game against Cake:

[Event "test game"]
[Date "2009-03-18"]
[Black "Cake 1.8"]
[White "Java engine"]
[Result "1/2-1/2"]
1. 11-15 22-18 2. 15x22 25x18 3. 8-11 29-25 4. 4-8 25-22 5. 12-16 24-19 6. 16-20 19-15 7. 10x19 23x16 8. 6-10 16-12 9. 9-14 18x9 10. 5x14 26-23 11. 2-6 22-18 12. 14-17 21x14 13. 10x17 31-26 14. 6-10 23-19 15. 1-6 19-15 16. 10x19 26-22 17. 17x26 30x16 18. 6-10 28-24 19. 10-15 18-14 20. 15-18 14-10 21. 7x14 16x7 22. 3x10 12x3 23. 18-22 3-7 24. 22-26 7-2 25. 10-15 2-7 26. 15-18 7-10 27. 14-17 10-14 28. 18-22 14x21 29. 26-31 21-17 30. 22-25 17-22 31. 25-30 32-28 32. 30-26 22-25 33. 26-30 25-22 34. 30-26 22-18 35. 26-30 1/2-1/2

This one draw doesn't mean too much of course - in its next game, it got into trouble against simple checkers, but just managed to escape with a draw. There is still a lot of knowledge missing in the evaluation function... And the GUI will need a lot more attention too!

Checkers for Android Phones

2009-08-11T22:05:00.004+02:00

It's been a while since I worked on my Java program. Actually, the underlying purpose of writing a Java checkers program was to (1) learn Java and (2) write a checkers program for the Android operating system running on the Google phones. There are two checkers programs for the iPhone based on my simple checkers engine, and since developing for the iPhone seems to be a PITA or at least some kind of licensing hell, I was never interested. The much more open philosophy of Android attracted me however, and my checkers program is already running on my emulator. It manages to search about 5000 positions per second, i.e. it's nearly 1000x slower than my corresponding PC program, and therefore also quite a bit weaker. But since it incorporates a lot of the stuff that I learned during the many years of programming Cake, it plays a decent game nevertheless. I worked hard on it during the last two weeks on my mountain holidays (whenever I wasn't climbing the mountains), and it's already a working program. However, I may have overdone things a bit trying to put a lot of features into the program, so it won't be ready today or tomorrow, but hopefully before the summer is out.

Java Checkers progress

2009-05-19T18:38:00.003+02:00

I've continued working on my Java checkers program, and it has an interface similar to CheckerBoard now, and plays a decent game (albeit without opening or endgame databases). I also worked on a beginner level that will be less frustrating than CheckerBoard is now!
However, work on the interface is slow, as I feared. I want to add PDN support, and while writing a PDN parser was simple, I find it quite hard to use the Swing Table to display the games when loading them. Oh well, at some point I will either give up on the PDN feature and publish anyway or find out how to use it....

CheckerBoard 1.7 & co.

2009-12-21T20:43:00.003+01:00

I just published a new version of CheckerBoard on my website. CB 1.7 has some minor bugs fixed, and doesn't write to the program files - CheckerBoard directory any more, which was a problem with the UAC (user account control) of Windows Vista and Windows Seven. Most of the changes in CB 1.7 were contributed by Ed Gilbert; thanks a lot Ed!
The CB source code is also available, but still rather difficult to comprehend.

I also updated the engines to comply with Vista/Win7, Cake and the Kingscourt engine didn't work with the new OS versions unless run with administrator rights. The CB install package now also includes Suicidal Cake with a 4-piece endgame database for suicide checkers and an opening book. I worked on suicide checkers about 3 years ago, and thought it would be a shame to leave what might be the world's best suicide checkers program rot on the shelf...

Java perft

2009-03-03T23:12:00.005+01:00

I just finished debugging a Java checkers move generator - thanks to perft I found some bugs, and just watched the first game of my Java checkers engine played against itself (not a nice sight). Not surprisingly (at least to me), the Java code runs much slower than the C code - I found a factor 3.2 difference. Is that just me, or is it Java??

C (Cake's code without move ordering)
depth 1 positions 7 time 0.000000 1.$ kN/s
depth 2 positions 49 time 0.000000 1.$ kN/s
depth 3 positions 302 time 0.000000 1.$ kN/s
depth 4 positions 1469 time 0.015000 97.9 kN/s
depth 5 positions 7361 time 0.000000 1.$ kN/s
depth 6 positions 36768 time 0.000000 1.$ kN/s
depth 7 positions 179740 time 0.000000 1.$ kN/s
depth 8 positions 845931 time 0.063000 13427.5 kN/s
depth 9 positions 3963680 time 0.156000 25408.2 kN/s
depth 10 positions 18391564 time 0.547000 33622.6 kN/s
depth 11 positions 85242128 time 2.656000 32094.2 kN/s
depth 12 positions 388623673 time 12.266000 31683.0 kN/s

Java
perft 1:7 1ms 7000positions/sec
perft 2:49 1ms 49000positions/sec
perft 3:302 1ms 302000positions/sec
perft 4:1469 17ms 86000positions/sec
perft 5:7361 1ms 7361000positions/sec
perft 6:36768 16ms 2298000positions/sec
perft 7:179740 17ms 10572000positions/sec
perft 8:845931 79ms 10707000positions/sec
perft 9:3963680 392ms 10111000positions/sec
perft 10:18391564 1813ms 10144000positions/sec
perft 11:85242128 8486ms 10045000positions/sec
perft 12:388623673 39141ms 9928000positions/sec

A postscript a couple of days later: I managed to improve my Java code a bit, it is now only 2.3 times slower than the C code. I suppose that is about the best one can hope for with Java - or??

perft for checkers

2009-02-15T21:31:00.003+01:00

A couple of days ago I got a mail from Aart Bik, a programmer working at Google. He is currently developing a checkers application (among others) for the Google android platform (aka gPhone). He asked me about perft numbers for checkers. Perft is an invention of the chess programming community, a test to verify the correctness of the move generator, by printing how many legal moves exist in a search tree to depth N from the current position. Although I have this function in my chess engine, I never thought of adding it to Cake until now. However, Aart is right, and a perft function is always good to have for debugging purposes, so I added it to Cake. In the next CheckerBoard/Cake release, Cake will have this functionality. For starters, here are the numbers Cake reports from the initial position:


depth 1 positions 7
depth 2 positions 49
depth 3 positions 302
depth 4 positions 1469
depth 5 positions 7361
depth 6 positions 36768
depth 7 positions 179740
depth 8 positions 845931
depth 9 positions 3963680
depth 10 positions 18391564
depth 11 positions 85242128
depth 12 positions 388623673

Aart is happy too, since his numbers match. If you are interested in his applications for the gPhone, then check out his blog.

Dweeb!

2009-01-26T22:31:00.003+01:00

I just heard that Jonathan Schaeffer published a revised version of his book on Chinook, One Jump Ahead. I own it, and it was one of the things that motivated me to work on checkers. In the new version, some new material was added on the solution of checkers by the Chinook team, which probably also makes good reading. I also get mentioned in the book - although I'm rather on the receiving end:

"Darse Billings and many other people were upset at the junk that was being posted on the web. Darse sent out the following message:

Who the hell is this dweeb? I read the report of the Las Vegas tournament and was appalled with his obnoxious and slanderous comments against Jonathan. Someone should teach him some manners.
Personally, I see no reason for Jonathan to accept a challenge from NEMESIS - CHINOOK doesn't have to prove anything to anywone. The program did enough talking eight years ago - long before the pipsqueaks started squeaking. But if he does grant them a match, I hope it will only be after sufficient preparation to blow them out of the water. Punks."

Darse (and Schaeffer with his Junk) is referring to my report on the Las Vegas world championship (As a side note, Darse was not on the Chinook team, and not a checkers programmer - exactly what his qualifications would be to judge the claims in my report remains a mystery to me).

Well, at least I learned some new English curse-words :-)

4 in a row source code

2008-08-07T00:30:00.003+02:00

I just published the source code of my 4 in a row program on my four in a row page. While this doesn't appear to fit in a computer checkers blog, I think it does belong for two reasons: first, it is an example of how to write a high-performance game program. Second, this is the second part of my plan to publish some of my source code (CheckerBoard came in first). More to follow...

CheckerBoard source code release

2008-07-22T22:45:00.003+02:00

My interest in computer checkers is waning - partly because the game is solved, partly because other interests are taking more of my time these days. I still sometimes get mail asking for new features in CheckerBoard, but I haven't done much lately. Since I don't think this will change anytime soon, I have made the source code of CheckerBoard (in version 1.651) public. This code can be used in any way you might see fit; I'm not going to bother with some kind of public license.
I am very much aware that the code is neither particularly good nor clean; CheckerBoard was - like perhaps most software - not really designed well, i.e. it started out as a simple program and then I kept on adding more and more things to it, and so the whole program structure isn't nice. Some of the source code is really old, written at a time when my programming skills were even less developed than they are now. And of course, I'm not a trained programmer who learned how to properly develop software. All of this will make the CheckerBoard source code rather hard to understand, but if you have a lot of patience and a decent working knowledge of standard C, then you can probably get to grips with it.

CheckerBoard 1.651

2008-07-18T12:37:00.002+02:00

I just published CheckerBoard 1.651 on my webpage. This release fixes four things:

1) a serious synchronization bug between the multiple threads of CheckerBoard, which could show up in autoplay and engine match mode; on my two newer machines that I usually use for development, this bug didn't show, but on my oldest machine it was very obvious. Even if the bug didn't show clearly on the newer machines, it is possible that it affects engine match outcomes - an upgrade is therefore strongly recommended if you run engine matches.

2) a small bug with graphics updating when changing the piece set (the board would update, the pieces only on the next window resizing).

3) export to HTML now also works from setup positions for Italian checkers (it always worked for English checkers)

4) I forgot to include the file 11man_FEN.txt which is used for 11-man engine matches. It contains 2400 of the 2500 possible 11-man starting positions. 100 of the positions are omitted, because they are likely wins for one side. The newest release includes this file, so that 11-man engine matches with 4800 games can be run (if you have the patience...) for better statistics than with standard engine matches.

If I get no negative feedback on this release, I will also publish the source code of CheckerBoard, since I find it increasingly difficult to find the time to work on CB - making the source public is a better alternative to stopping the development altogether.

But now, enjoy your bug-free 11-man matches!

CB 1.65 bug

2008-07-13T20:06:00.003+02:00

It has been nearly 3 months since I released CheckerBoard 1.65, and I hate to admit that I got bug reports nearly instantly after its release. I finally took the time to look into them (partly because my girlfriend is in Spitzbergen). I cleaned up a lot of my source code in CB 1.65 with the goal of making it public with this release, and unfortunately, I managed to add a rather serious synchronization bug to it. I believe to have found it, some final testing is still required, but probably there will soon be an update available.

Engine match mania

2008-02-22T19:53:00.007+01:00

Over the last week, I tested several versions of my latest checkers engine (which carries the rather bland name Cake 1.8) - and I did this on all of my three computers. I own a AMD64 desktop, a CoreDuo laptop and a CoreQuad Desktop. These machines are all about equally fast; the CoreQuad is a bit faster than the other two, it also runs a 64-bit windows. Here are the results of my engine matches against KingsRow 1.16c:


Engine           CoreQuad CoreDuo  AMD64    total
-------------------------------------------------
Cake 1.8 v1      +28-12   +27-18   +27-20   82-50
Cake 1.8 v2      +19-17   +25-17   +32-15   76-49
Cake 1.8 v3      +23-15   +24-19   +27-17   74-51
Cake 1.8 v4      +21-15   +23-17   +26-17   70-49
Cake Manchester  +23-11   +24-13   +24-21   71-45

The results are a mess! I ordered the different versions of Cake 1.8 according to their overall result, and while you can see that v1 is best overall, it is worse than v2 on the AMD64 and worse than Cake Manchester on the CoreDuo. Which means that if I had only been testing on the CoreDuo, I would have been disgusted with the performance of my new program, because it's worse than the old one, and if I had been testing on the AMD64, I would have chosen v2 rather than v1. Which of course means that running engine matches on a single computer (as I did for the past 7 years or so) is clearly insufficient, and it also casts some doubt on the current methodology of using 3 computers - how do I know that using 3 computers is enough? Wouldn't 10 be better? All in all, this is quite a disgusting discovery, and I'm at a bit of a loss of how to proceed when optimizing my engine :-(

Bug squashing

2008-02-07T23:09:00.000+01:00

Yesterday and today I found bugs in Cake's evaluation. I was looking at some games that Cake had lost, and made a change in the evaluation which should have improved the situation. However, although the evaluation was different, the output of the engine remained the same - the exact same number of nodes searched with the same value for the position. That made me *very* suspicious, and I looked at the code a bit more closely, and discovered that during my code cleanup of last summer I had broken a really important piece of knowledge. Being suspicious, I continued looking for bugs and found one minor bug and one cosmetic bug. The match result improved drastically after stomping the first bug, from +19-16 @5s/move to +26-11. I don't have much hope that the minor bug will make a big difference but soon I will see!

Multi-Core speed

2008-02-04T22:23:00.001+01:00

Nowadays, CPUs aren't getting much faster in terms of clock speed, but the manufacturers are putting multiple cores in one CPU. While this gives a lot more bang for the buck, it is a challenge for programmers to make use of the newly available resources. Some problems are easy to parallelize, while others are much more difficult. Unfortunately, tree searching such as in two-player-strategy-games belongs to the second class: it's not straightforward at all to implement a parallel game tree search. Of course there are solutions for this, the best-known is called YBWC for young brother wait concept. This is quite easy to explain with words, but really programming it is something different :-(
I haven't managed to find any sensible description of the algorithm with some real code, except for the source code of Crafty, a strong free chess engine. While this is documented quite well on the source code level, there are very many source code files and many of them have the required changes for the parallel search, and it's all very confusing to me. I wonder if there is any sensible YBWC tutorial anywhere on the net?

Anyway, my own plans were different to start with: All I wanted to do was to make my book generator work in parallel - it is quite easy to have multiple threads running on a multi-core-CPU when each thread is just doing a standard search on its own position. The big difficulty only arises when all threads are supposed to help search the same position, because they have to start communicating with each other.

The only problem in having multiple threads running simultaneously is the following: the endgame database access code has to be protected from being accessed by multiple threads, since confusion could occur when two threads try to load data from disk at the same time. In such situations programmers use a "lock" to prevent other threads from accessing critical code when one thread starts using it. This thread has to free up the critical code again once it is done, so that the other threads can also use it. Obviously, this whole process might slow down the program a lot, because one thread can be blocking the others - and the only way of knowing whether this is a problem is to try! I made Cake thread-safe last summer, and finally tested the speed on my new quadcore yesterday. Here is the result:

1 thread: 2050 kN/s
2 threads: 2000 kN/s
4 threads: 1815 kN/s

Running 2 threads simultaneously thus results in a speed loss of about 2.5%, while running 4 threads gives a loss of 11%. Of course, that is not a big price to pay, since in total you are getting 4x89% = 356% out of your CPU compared to having a single thread running. I also have to admit that I just put the whole database lookup call in a critical section; perhaps it is possible to make that more efficient by only putting the parts of the database lookup that affect the database cache in a critical section. Nevertheless, I'm afraid I have no excuses any more and should be working on a multi-threaded book generator now...

Heavyweight match

2008-01-17T23:17:00.000+01:00

I just finished running an engine match between the 64-bit versions of Cake and KingsRow. Cake managed a narrow win, but what makes even happier is that the entire engine match ran without problems, i.e. CB64 and Cake64 and KingsRow64 are all stable enough to run for 12 hours without any errors. I will probably publish the 64-bit versions in a couple of weeks.

As an aside, I got so annoyed with Windows Vista UAC (user account control) popping up TWO message boxes to confirm when I just want to rename a file that I ended up disabling UAC. I really wonder what the MS guys were thinking when they invented this feature. One message box for renaming a file would already be a huge PITA, but two... I guess the only people who don't disable UAC are those who don't know how to do it!

Some more Vista madness: I also noticed that by default my system was set to defragment its harddisk daily, run a full virus check daily, and run the pretty much useless Windows Defender. My system (a QuadCore with 4GB RAM) used to access the harddisk permanently for about 15-30 minutes after the system start. With all this stuff disabled, it is much better. In my quest for energy efficiency, I bought an 80+ power supply (80plus.org), which is not only energy efficient but also very silent (it only generates little heat and thus needs less ventilation than a standard power supply). However, with a loudish harddisk I didn't have any benefit of that. Now I do :-)

64-bit speedups

2008-01-14T21:32:00.000+01:00

I tried to find out how much performance increase a 64-bit compile will give compared to the 32-bit compile. I tested three different programs: my Connect 4, Cake and KingsRow. I also have a speedup reported by Ed Gilbert for his international checkers program, KingsRow-10. Here are the numbers:

KingsRow: 5.8%
Cake: 6.4%
Connect 4: 11.6%
KingsRow-10: 42.9%

This list shows that all programs are able to benefit from the 64-bit compile, although the gain is rather moderate for all programs except KingsRow-10. Why can some programs benefit more than others? Probably this has to do with how much they make use of 64-bit operations. For example, my Connect 4 program uses a 64-bit representation of the board. KingsRow and Cake use 32-bit representations and don't really have any use for the larger word size on the 64-bit machine. KingsRow-10 on the other hand also uses 64-bit numbers for its board representation and benefits much more than any other program on the list.

With all these numbers I have to add that there are some points to be considered: The KingsRow 32/64-bit versions don't seem to search the exact same tree - in kN/s searched, KR-64 was 5.8% faster, but its search time was only 2.6% lower. Additionally, KR wasn't using the endgame database during this test, since it doesn't recognize it for some reason on my system. Cake 32/64 searches exactly the same number of nodes on the one-minute search I used for this test. Cake32 makes use of some assembler instructions which Cake64 does not, so probably the speed difference would be a bit larger if I found out how to program these functions in 64-bit assembler. The same is true for Connect 4 (For the experts: I don't have a LSB function in assembler for the 64-bit versions).

Cake 64

2008-01-13T23:30:00.000+01:00

I recently bought a new motherboard/CPU for the computer that was generating the opening book database for Cake. My new machine is the most powerful I ever had, with a Core Quad and 4 GB of RAM. For curiosity's sake, I also installed Windows Vista on that machine. I'm not at all convinced by Microsoft's new OS, but at least it gives me the opportunity to finally run my 64-bit compiles myself. Thanks to this, I found the bug in the 64-bit version of Cake, and of course it was a 32/64-bit issue. I was computing the size of a memory block full of pointers for the endgame database with

char *pointer;
int memsize = blocknum * sizeof(int);
pointer = malloc(memsize);

since I had assumed that sizeof(int) would change to 8 byte on the 64-bit machine. But it stayed at 4 bytes, while pointers do need 8 bytes, and of course the whole thing crashed. I replaced the sizeof(int) with sizeof(pointer) and now it works. It appears that this was the only portability issue; I now have a working 64-bit version of Cake on my machine. By a strange coincidence I clocked it to be 6.4% faster than the 32-bit version.

Housekeeping

2007-08-22T18:20:00.000+02:00

I recently inherited the house of my grandfather, and now have a lot more housekeeping to do than earlier. Somehow, this might have helped me in my decision to do some housekeeping with Cake. Those of you who have programmed probably know the feeling: even if you started out with a more or less clean concept (I certainly didn't with Cake), things eventually get out of hand. You add an idea here, put in a quick fix there, and before you know it, your code is unreadable and unmaintainable. That's about the state that Cake was in before my summer holidays in the Austrian mountains. There, besides reading the Harry Potter finale and climbing some mountains, I cleaned up Cake's source code during two whole weeks. That much time is necessary, since you really have to stand back, and get an overview over your whole program to decide exactly how you want to do your cleaning up. You can't just do it on a single day, or fix it by programming one evening per month - until you get back to programming, you will have forgotten everything again (at least that's what would happen to me, but then I turned 36 recently!).
The result of two weeks of hard programming is that there are no global variables left in Cake, that Cake can be switched to thread-safe mode (at a small speed penalty), and that much of Cake's code is now much clearer and cleaner than before. It doesn't play any better at all though - but now that I have (nearly) finished the housekeeping part, I might be more inclined to work on it again!