Up until now I have not considered technical issues when writing the code. Things like allocating a new object takes alot of time.
I started with a rather slow code in general, with many objects getting stored and moving back and forth, and every change I made so far has tried to speed up the code with things like move ordering and reduction of the search tree (transposition tables, killer moves, null-move pruning etc. etc.).
Now when it is time to add things like move extensions, pawn structure evaluation and attack tables, we are starting to slow down the search again.
So before doing that I think we need to speed up the core of the engine.
When doing a 'perft 4' (finding all positions after 4 plies from start position), Mediocre allocates 207064 Move-objects. These objects also have to be collected by the Java garbage collector when they are not used anymore. If we were to use an integer to represent those moves instead we would speed up this process tremendously.
Compared to other engines I have tried, the 'perft' command is about 20-30 times slower in Mediocre on average. Perft only uses generateMoves, makeMove and unmakeMove so it is easy to conclude there are some massive time saving to be found there.
I think it is about time we do something about this. I will finish up with the new changes to the evaluation, so castling and better piece development is rewarded, and also fix a few issues with time management and support for analyzing in winboard and uci. And release v0.21b.
Then start working on optimizing the code, removing allocation of unnescessary Move-objects and overall tweak the performance. This is where real gains can be found at the moment I believe.
3 comments:
That looks very promising. The search seems well done (not too many nodes considered to reach a given depth), only the nodes per second are still rather low (although there was a noticeable improvement in v0.2). Keep up the good work!
You might consider writing your engine in C for speed.
Never! How could I write a Java-engine in C? :)
Besides the gap between Java and C concerning speed is shrinking every new release of Java. The factor is getting so small that you would have to be a damned good programmer to not eliminate the difference with programming flaws.
Post a Comment