Interview with Allard Siemelink (The Netherlands)
Programmer of Bright and Spark
10th, January 2010
by Allard Siemelink & Frank Quisinsky
Allard Siemelink (The Netherlands)
Deutsch: Im Jahre 2008 sorgte Bright, nicht nur aufgrund seiner ausgeprägten taktischen Fähigkeiten, für Aufmerksamkeit. Auch hinsichtlich Spielstärke platzierte sich Bright auf Anhieb unter die TOP 20 der Weltelite der Schach-Engines. Im Oktober 2009 veröffentlichte, der heute 43jährige niederländische Programmierer Allard Siemelink, mit Spark eine zweite Engine.
ENGLISH: In 2008 Bright arrest attention with his strong tactial skills. Bright placed himself among the TOP 20 of the world elite of chess engines. In October 2009, the now 43 year-old Dutch programmer Allard Siemelink published with Spark a second engine.
Hallo / Hello Allard,
Deutsch: Schön das Du uns über Bright / Spark exklusive Informationen zur Verfügung stellen möchtest.
ENGLISH: Nice that you will give us exclusive information about Bright / Spark.
Interview Teil 1 / Part 1
Deutsch: Zunächst, warum entwickelst Du mit Bright und Spark zwei Engines zeitgleich. Wurde Dein neueres Programm Spark komplett neu programmiert, so dass Spark zukünftig im Blickpunkt stehen wird?
ENGLISH: First of all, why are you developing with Bright and Spark simultaneous two engines at the same time? Your recent Spark engine has been completely rewritten, so that Spark will be found in future in the spotlight?
During 2008, I found that it became increasingly hard to improve Bright much further. As a diversion, I created a bitboard board representation along with a (perft) benchmark, just to see how that would fare on a 64 bit Linux platform. Unsurprisingly, the bitboard code ran much faster than the equivalent 0x88 board representation that is used in Bright. At the same time, I felt that it would help Bright's development if I would have an experimental engine on the side that I could use to explore new ideas in search and evaluation. So I took the bitboard perft code and started Spark.
To make sure I would not merely recreate Bright as a bitboard engine, in which case I would learn nothing, I decided to start from the ground up and develop the search and evaluation from scratch and to try as much as possible alternative search strategies and evaluation terms for the ones that are found in Bright.
Naturally, I have re-used as much plumbing code (such as the Zobrist keys, UCI protocol handling, testing code and so on) as I could from Bright, basically anything, that does not affect the search or the evaluation.
Currently I find myself at a point where Spark's search seems to have surpassed Bright, reaching much higher depths. I tend do think that Bright's evaluation is still better at this point though, it is certainly more complex, e.g. Bright evaluates 'hidden' attacks on the king, while Spark has no such concept. Eventually the best of both engines will be unified and only one will remain.
Deutsch: Bright ist mehrprozessorfähig und nutzt die egbb Endspieldatenbanken. Spark hingegen kann derzeit noch nicht mit diesen Möglichkeiten aufwarten. Dennoch erreicht Spark eine um ca. 30 ELO höhere Spielstärke als Bright (möglicher Vergleich bei der Nutzung von einem Core / Prozessor).
ENGLISH: Bright is an multiprocessing engine and uses egbb endgame databases. Spark however, can't come up with these possibilities yet. Nevertheless Spark is playing a higher level by about 30 ELO as Bright (possible comparsion with using one core / processor).
Deutsch: Wird eine Mehrprozessor-Version von Spark in Zukunft auch zur Verfügung gestellt?
ENGLISH: Will be a multiprocessing version of Spark available in the future?
Deutsch: Wird auch Spark kompatibel zu Endspieldatenbanken werden? Vielleicht überlegst Du auch die bekannteren Nalimov Endspieldatenbanken zu implementieren? Vielleicht kannst Du uns bei der Gelegenheit mitteilen, warum Du Dich für die egbb Endspieldatenbanken und nicht für die Nalimov Endspieldatenbanken bei Bright entschieden hast.
ENGLISH: Will be Spark also compatible with endgame databases? You might also think about to implement the more popular Nalimov endgame databases? Maybe you can take the opportunity to tell us why you decided for the final egbb databases and not for the Nalimov endgame databases at Bright.
It is. As a matter of fact, Spark 0.3a MP has just been released. And according to CEGT and CCRL, it scales pretty well too: on 4 cpu's, it should play 120 elo stronger than the single cpu version.
Endgame tablebase support is planned for a future version. Ideally, I would like to support both bitbases and DTM/DTC tablebases. The bitbases have the advantage that more positions fit into memory and therefore, the search can probe them very efficiently. This is the reason why Bright uses bitbases. However, once a winning position has been reached on the board, a bitbase does not have any information on how to secure that win (or best delay a loss). DTM (distance to mate) or DTC (distance to conversion) tables will help in case the search cannot find the path to mate itself. Unfortunately, the Nalimov tablebases require complicated code to be linked in with the engine and there are some license issues. I've just never gotten around to sorting this out. On the other hand, I may not have too: it looks like Miguel Ballicora's Gaviotta tablebases will soon be available.
Deutsch: Bleiben wir bei der implementierten „Mehrprozessorfähigkeit“ von Bright. Es ist auffällig, dass Dir die Implementierung besonders gut gelungen ist. Nach meinen Testergebnissen liefert Bright einen der höchsten Geschwindigkeitsfaktoren aller Engines. Es gilt als allgemein bekannt, dass bei 2 Prozessoren programmiertechnisch maximal ein Faktor von 1.7 – 1.8 erreicht werden kann. Eine Verdoppelung der Geschwindigkeit (Faktor 2.0) bringt nach heutigen Erkenntnissen ca. 60 ELO. Konntest Du aufgrund eigener Ideen diesen Bereich der Schachprogrammierung verbessern?
ENGLISH: Let's stay with the implemented "multiprocessing" by Bright. It's eye-catching that you have managed the implement very well. After my test results Bright provides one of the greatest speed-factors of all engines. It's generally known, that in technical programming with 2 processors maximum a factor 1.7 - 1.8 can be reached. According to current knowledge a doubling of speed (factor 2.0) brings about 60 ELO. Could you improve by your own ideas this area of chess programming?
That's interesting, I am not familiar with the theory behind the 1.7 - 1.8 speedup limit, nor do my engines seem to be affected. What I am doing is basically a standard YBW (Young Brothers Wait) algorithm. What sets it apart from other engines is appearantly a more efficient implementation. For instance, as far as I am aware, most engines do not split the search tree at shallow depths as that would hurt their performance. As splitting is a cheap operation (avoiding an expensive copy of the board and associated data) for both Bright and Spark, they can and do split the search tree at any depth, maximizing the use of the otherwise idle cores.
Deutsch: Betreibern von Ratinglisten stellst Du gerne nicht veröffentlichte Entwicklungsversionen von Bright / Spark zur Verfügung. Letztendlich brodelt hierdurch die Gerüchteküche!? Wirst Du auch zukünftig Versionen von Bright / Spark als Freeware zur Verfügung stellen, oder hegst Du kommerzielle Absichten?
ENGLISH: You like to give non-published development versions of Bright / Spark to operators of rating lists . Ultimately, thereby the gossip factory (rumor) bubbling. Will you make versions of Bright / Spark available as freeware in future or did you have commercial interests.
Currently, I am working on a cheap commercial chess engine for the iPhone, it will be based on Spark, with the best of Bright thrown in and it will have a nice GUI. For the PC, I have no commercial plans at the moment as I doubt it would be a profitable and hassle free enterprise.
Deutsch: Eine Standardfrage, die ich zukünftig in allen Interviews mit Schachprogrammierern einfließen lasse. 64-Bit erfreut sich einer immer größeren Beliebtheit!
ENGLISH: A standard question which I will ask in all future interviews of chess programmers. 64-Bit enjoys a growing popularity!
Deutsch: Optimierst Du Deine Programme bevorzugt auf 32-Bit oder eher auf 64-Bit?
ENGLISH: Do you optimize your engines with 32-Bit or more on 64-Bit?
Deutsch: Profitiert Spark von der 64-Bit Implementierung?
ENGLISH: Do Spark profited from the 64-Bit implementation?
Until recently, my primary development system has been 32-bit/AMD. So naturally, my engins are somewhat optimized for that platform. Now that I've upgraded my primary system to 64-bit/Intel, future versions will inevitably become better optimized for these platforms.
Sure, Spark runs 40%-50% faster on 64-bit platforms, which should make it around 20-30 elo stronger than the 32-bit version.
Deutsch: Bei unserem Interview mit Don Dailey (Doch) kam sehr schön heraus, dass Don seit vielen Jahren mit GM Larry Kaufmann zusammen arbeitet. Es ist selten zu beobachten, dass Schachprogrammierer eine Art „Mentor“ haben. Schachprogrammierer sind keine IMs oder GMs und sind sicherlich über Hinweise von Schachmeistern dankbar. Was hältst Du von der Idee „Patenschaften“ einzurichten? Hättest Du ein Interesse Dich hinsichtlich Deiner Programmentwicklung mit einem Großmeister auszutauschen?
ENGLISH: In our interview with Don Dailey (Doch) it showes us very nice, that Don was working together with GM Larry Kaufmann for many years. It is rarely observed that chess programmers have a kind of "Mentor". Chess programmers are not IMs or GMs, and are certainly grateful for indications / hints of chess masters. What do you think about the idea to create a sponsorchip with chess grandmaster? Do you have interest in sharing information with a grandmaster for improving your developements in chess engines?
Well, I think Larry Kaufmann proved with Rybka and now with Doch that this kind of cooperation certainly can pay off. In my case, I am pretty sure that there are all kinds of weaknesses that I am not even aware of. So, I gather human expertise would be of great help in advancing to a higher level of chess play, and I would certainly welcome that, of course.
Deutsch: Bleiben wir bei dem Thema der vorherigen Frage. Chrilly Donninger (Programmierer von Nimzo) hatte vor ca. 12 Jahren die Idee, dass Anwender seinem MS DOS Nimzo 3 Schachwissen implementieren können. Die Idee geriet in Vergessenheit. Wäre es möglich, vergleichbar zu den Protokoll-Ideen UCI oder Winboard, ein Protokoll für die einfache Implementierung von Schachwissen zu kreieren?
ENGLISH: Let's stick to the topic of the previous question. About 12 years ago, Chrilly Donninger (programmer of Nimzo) had the idea, that users can implement chess knowledge to MS DOS Nimzo 3. The idea was forgotten. Would it be possible, to create a protocol, similar to the protocol ideas Winboard / UCI, for a simple implementation of chess knowledge?
Unfortunately, I am not familiar with Chrilly's idea. Perhaps such a system could be created, but I do not think it would be easy. Anything more complex than tuning evaluation parameters would most probably slow down the engine and lose elo opposed to coding the same rule in the evaluation function. But this is rather complex and not for everyone. So the problem becomes to define a language for chess knowledge that is easy and powerful yet can be executed efficiently. I see no obvious answer for this.
Interview Teil 2 / Part 2
Deutsch: Im zweiten Teil des Interviews beschäftigen wir uns intensiver mit der taktischen Stärke von Bright / Spark. Als vor ca. 12 Jahren die Winboard Engine Phalanx für atemberaubende Königsangriffe sorgte, verstand eigentlich niemand so Recht warum Phalanx gerade hier so außergewöhnliche Fähigkeiten hatte. Selbst der Programmierer konnte es nicht so richtig verstehen. Er wies mich seinerzeit darauf hin, dass er Phalanx kein spezielles Wissen implementiert hat. Das alles ist sehr lange her und die Schachprogrammierung ist inzwischen weit fortgeschritten.
ENGLISH: In the second part of the interview we are busying intensively with the tactical strength of Bright / Spark. About 12 years ago, as Phalanx Winboard Engine caused stunning king attacks, no one understood why phalanx just had been so extraordinary abilities here. Even the programmers could not understand it properly. At the attention he pointed me to the fact that he has implemented phalanx no special knowledge. All this is very long ago, now chess programming is well advanced.
Deutsch: Es muss Gründe für die außergewöhnlichen Fähigkeiten von Bright / Spark im Taktik-Bereich geben. Sind es die Bewertungsfunktionen, andere Programmteile oder spezielles Wissen? Möchtest Du uns anhand von Auszügen Deiner Sourcen erklären, welche Ideen Du hast?
ENGLISH: There must be reasons for the exceptional skills of Bright / Spark in tactics. Is it the evaluation function, other parts of the program or special knowledge? Would you explain to us, what ideas do you have, by parts of your sources?
Although both Bright and Spark have pretty hefty bonusses for attacking ennemy pieces and weak pawns, I gather the search is more important for strong tactics. At least that is how I developed both Bright and Spark: both engines started with a simple material-only evaluation. Then, for months, I focused on the search, using tactical test suites for validation and carefully examining the shapes of the search trees. When finally adding the positional evaluation terms, it never seemed to do much to further improve tactical ability.
Actually, I feel there is already plenty of strong engine source code out there, certainly enough for anyone to get into the game and/or improve their engines to be very competitive. For the chess community as a whole, I feel it is better served by allowing some diversity as well. So, I won't show any source code, the interesting parts of which would be too long and technical for an interview setting anyway. What I can do is share some ideas, e.g. show some example positions and illustrate some ideas that help solve them.
Deutsch: Gibt es taktische Stellungen, die Du besonders gerne bei Deiner Testarbeit einsetzt? Vielleicht könntest Du uns 4 benennen.
ENGLISH: Are there any tactical positions that you particularly like to use in your test work? Perhaps you could give us 4.
Although I don't think individual positions are very important for practical playing strength, I do have a few favourites.
4r1k1/p1qr1p2/2pb1Bp1/1p5p/3P1n1R/1B3P2/PP3PK1/2Q4R w - - bm Qxf4; id "WAC141";
The best move is Qxf4!, eventually leading to a rook's mate on h8.
With all my engines I have struggled to find this one quickly, without blowing up the search tree in other positions where matethreats are not an issue. Spark has static mate threat detection allowing it to solve this position quite quickly.
1nbq1r1k/3rbp1p/p1p1pp1Q/1p6/P1pPN3/5NP1/1P2PPBP/R4RK1 w - - bm Nfg5; id "WAC293";
Another position of the WAC test suite. Although it is only a mate in 4, many engines do not find it very quickly. Spark needs only 6 ply to find the mate.
5k2/8/8/8/8/2P5/8/3K4 w - - bm Kc2; id "UskiEG01";
A basic endgame position. The winning move is Kc2, all other moves draw. Both Bright and Spark have special pawn endgame evaluation rules to quickly see that Kc2 is winning. In fact, Spark even evaluates the position as winning, while Bright requires a short search.
8/k7/3p4/p2P1p2/P2P1P2/8/8/K7 w - - 0 0";
(Diagrams are from Shredder 12 GUI)
A well-known endgame study by Ruben Fine. The winning move is Kb1! Whenever I change some code in the transposition table, this is the first position to verify that nothing was broken. All good engines solve this one quickly, wait a couple of minutes and Spark will announce mate in 32.
Deutsch: Möchtest Du uns weitere Quellen-Hinweise zum Thema „Taktik“ geben? Woher beziehst Du Dein fundiertes Wissen? Vielleicht aus Schachbüchern oder anderen Quellen wie Sourcen von Schachprogrammen? Welche fremden Quellen haben Dich inspiriert?
ENGLISH: Would you give us another source notes in "tactics"? From where do you get your sound knowledge? Perhaps from chess books or other sources such as sources of chess engines? What other sources have inspired you?
It is quite simple really. For testing tactical prowess, I use tactical test suites, like I mentioned. To assist me in deciding whether a change is good, I have developed a suite runner utility. Not only does it tell me the number of positions solved, it also keeps a tally of the required depths, number of nodes, nodes per second and a number of other, less important, statistics. Versions that solve the test problems faster are usually also stronger when playing games. The suite runner utility is also a great help while tuning for performance: it has prevented many a bug by instantly detecting any unintended changes in search and evaluation.
Like most engine developers, or so I presume, I have also looked at open source programs and I have tried ideas that I've found there. LMR (Late Move Reductions), introduced and popularized by Fruit and Glaurung are an idea that I use both in Bright and Spark, but the details are different. In Bright and Spark, the reductions are not history based, nor are they 'late' in any sense. All moves, except the first one, can be reduced by one (Bright) or upto two (Spark) ply, depending on static criteria.
For inspiration, I also read the occasional chess book, e.g. The Art of Attack in Chess, by Vukovic or Jeremy Silman's books.
11. Frank Quisinsky
Deutsch: Schließen wir das Thema mit drei Folgefragen ab.
ENGLISH: We conclude the issue with three follow-up questions.
Deutsch: Wirst Du dich weiterhin im Bereich Taktik spezialisieren oder vielmehr bestrebt sein Dein Programm von vorhandenen Schwächen in anderen Bereichen zu befreien.
ENGLISH: Do you continue to specialize yourself in tactics, or did you try to improve your engine in existing weaknesses to other parts.
Deutsch: Wo liegen Deines Erachtens die Schwachpunkte bei Deiner neuesten Entwicklung Spark?
ENGLISH: Where are the weaknesses in the new development of Spark by your opinion?
Deutsch: Gibt es Bereiche der Schachprogrammierung an denen Du verzweifelst? Welche Fragen quälen Dich, stellen Dich vor unüberwindbare Hürden?
ENGLISH: What are there areas of chess programming in which you despair? About which questions do you worry and built an insurmountable hurdle to you?
To me, playing strength is more important than tactical strength. Fortunately, they seem to go hand in hand, so there has been little need to willingly reduce tactical ability thusfar.
I believe the evaluation could still be much improved. For Bright, I developed a statistical analysis tool to tune Bright's evaluation for maximum concordance with human assessment of nearly all aspects of it's evaluation, based on a large number of quality human games. I started to do the same for Spark's evaluation terms, but it is still work in progress.
Not really, I usually have plenty ideas to try. Of course, from time to time I do get stuck on something. Rather than despair I just start to work on something else and return later with fresh ideas.
Interview Teil 3 / Part 3
Deutsch: Im dritten Teil beschäftigen wir uns mit allgemeinen Fragen zum Thema Computerschach.
ENGLISH: In the third part we deal with general questions about computer chess.
Deutsch: Die Niederlande zählen zu den Computerschachhochburgen. Viele bedeutende aktuellere und auch ältere Programmentwicklungen kommen aus den Niederlanden. Wie bist Du selbst zu Computerschach gekommen? Dienten Dir die niederländischen Entwicklungen als Vorbild?
ENGLISH: The Netherlands are among the computer chess strongholds. Many recent and actual developments comes from the Netherlands. How did you even come to computer chess? Did the Dutch developments served you as a model?
In 1999, when I was working as an ICT consultant for CMG (now Logica), some colleagues started a company compitition for who could write the best chess engine. It took me two weeks to create something in Java, and although it was slow and only searched 5 plies deep, it did manage to beat the competition, which incidentally consisted of the two tournament organisers themselves only. Later, when I first learned about bitboards, I just had to give that idea a try and I wrote a new Java engine based on that technique. And although it eventually did fairly well (it was probably 2500-2600 elo'ish), it turned out that Java just wasn't fast enough to be competitive. Have become fully infected by the computer chess virus by that time, I switched to C++ and eventually I created Bright.
13. Frank Quisinsky
Deutsch: Die Bedeutung von Computerschachturnieren lässt langsam nach. Immer weniger Programmierer nehmen an offiziellen Turnieren, wie die Computerschach-Weltmeisterschaft, Dutch-Open, etc. teil. Worauf führst Du das zurück? Es liegt wohl in der Natur des Computerschachs, virtuell seinem Hobby nachzugehen. Das Zwischenmenschliche geht dabei weitestgehend verloren. Hegst Du ein Interesse an solchen Turnieren persönlich teilzunehmen?
ENGLISH: The importance of computer chess tournaments will be more and more less. Fewer and fewer programmers participated on official tournaments like World Computer Chess Championships, Dutch Open, and others. What are the reasons for it? Is it probably the nature of computer chess, pursuing virtual the hobby. Here the interpersonal is largely lost. Do you have interest in participating such tournaments by yourself?
I like the idea of a tournament with physical presence of the contestants. However, these tournaments do require time investment of three days up to a week, which is really a bit too much for me. Of course, if someone would operate for me, that problem would be out of my way, but I am not sure whether that kind of participation is what the organisers of these tournaments intend to organise.
Yes I do. The virtual tournaments are for me easier to participate in. Both Bright and Spark have already participated in these kinds of events and will continue to do so in the future.
Deutsch: Verfolgst Du die großen internationalen Schachturniere von Großmeistern? Spielst Du gerne Meisterpartien nach? Hast Du einen Lieblingsspieler / in?
ENGLISH: Are you following the international chess tournaments of grandmasters? Do you like it to replay chess games from grandmasters? Do you have a favorite player?
My favorite player of all time is Kasparov. I keep track of current grandmaster tournaments through the newspapers and internet.
Deutsch: Zwei abschließende Fragen zu Spark. Unter der ChessBase GUI Fritz verliert Spark oftmals durch Zeitüberschreitung nach den Eröffnungszügen (Spark reagiert nicht mehr). Ist meine Annahme richtig, dass Du selbst die Fritz GUI bei Deiner Testarbeit nicht einsetzt? Welche Benutzeroberfläche (GUIs) setzt Du ein? Könntest Du Dir das Problem mit der Zeitüberschreitung unter der Fritz GUI näher ansehen?
English: Two final questions to Spark. Among the ChessBase Fritz GUI very often Spark lost on time after the opening book moves (Spark stops responding). Is it right that you don't use Fritz GUI for your test work? Which user interface (GUI) do you use for your test work? Please have a look to the 'lost on time' problem, which I have explained yet.
For playing many games with really short time controls (2 games/second), I use a private low-overhead utility. For longer time controls, I use Arena, as it is a nice free GUI and it allows me to watch some games. Thanks for informing me about the bug. It should be fixed in the just released version 0.3a.
Deutsch: Allard sendete mir ein Bild und schrieb
ENGLISH: Allard send me a pic and worte:
The screenshot shows Spark discovering the best move (Qxf4) on iteration 8 for the WAC 141 position.
Have thanks for your time Allard.
SCHACHWELT wish you and your family a lot of SUCCESS in your development of Bright / Spark!
New releases information:
- MP version, slightly stronger than previous public version 0.4a.
- enhancements: updated opening book and evaluation
- platforms: Windows 32-bit only
- MP version, stronger than Bright 0.5c
- bugfixes: occasional unresponsiveness should be fixed
- platforms: 32-bit: Windows; 64-bit: Windows, Linux, Mac OSX
Copyrights and Sources by http://www.schach-welt.de & Frank Quisinsky
Further publication of this interview is allowed and wished,
but with the permission of http://www.schach-welt.de only.
One condition is the complete casting (e.g. inprinted media).
Frank Quisinsky, January 10th, 2010