Henk wrote:Looks like you have to adopt a 70's style programming and language to get a real high node count.
Certainly not.
Look at Stockfish's source. That's not 70's style. That's a very modern C++ style.
They started the project before C++11 came around. With C++11 it would look even more beautiful, with no performance penalty.
You just need to know what you are doing.
Disclosure: I work for DeepMind on the AlphaZero project, but everything I say here is personal opinion and does not reflect the views of DeepMind / Alphabet.
Henk wrote:Seems that using iterator and visitor design patterns also do no good to performance. Even garbage collect slows it down. I use visitors in evaluation to visit pieces and get their value. I knew it was slow but did not care.
Garbage collection: you shouldn't be allocating things to be collected inside your main loop. Pools of objects should be preallocated and reused.
In general you should refrain from 'heavy' OO techniques inside your main loop - often the mechanics behind the scenes for such things accept a hit of hundreds of cycles which for most gui level features is entirely inconsequential. But when you're hoping to get done an entire node in a few thousand cycles it becomes a big deal if you're calling these things a lot. I'm not familiar enough with c# to be able to tell you whether your visitors fall into this category or if you're likely just using them wrong.
I don't see any beauty in source code. Each line is one too much. Especially C languages look ugly with operations as ++, &&, ||, null, <<, continue, break, <t> and partial evaluation etc. I also programmed in PASCAL and ADA and that looked much better.
Worse than reading my own code how bad it might be is reading other people's code.
Henk wrote:Seems that using iterator and visitor design patterns also do no good to performance. Even garbage collect slows it down. I use visitors in evaluation to visit pieces and get their value. I knew it was slow but did not care.
Garbage collection: you shouldn't be allocating things to be collected inside your main loop. Pools of objects should be preallocated and reused.
In general you should refrain from 'heavy' OO techniques inside your main loop - often the mechanics behind the scenes for such things accept a hit of hundreds of cycles which for most gui level features is entirely inconsequential. But when you're hoping to get done an entire node in a few thousand cycles it becomes a big deal if you're calling these things a lot. I'm not familiar enough with c# to be able to tell you whether your visitors fall into this category or if you're likely just using them wrong.
Yes I did that before. But code without the pools was shorter and less error prone and I did not care much about performance. So I removed the pools.
Might even be that calling virtual methods is too slow or doing recursion.
Molested Skipper. I removed all code which was bad for speed. Now nodes per second is greater than Fairy-max. But Skipper plays much worse. For evaluation was the main problem and now there is almost nothing left over.
So I start all over again and watch the speed after each code change. I hate PST so that's the last thing I will add if ever.
My plan is to release (after debugging the currently disabled features) the source code of it as a 'model engine' in the category 'very basic'. The source contains lots of comments (micro-Max style). Perhaps I will call it 'Simple'. (Or is that name already taken? As an alternative I could call it 'Kludgy'.) It will have options to switch the various evaluation features (drawishness, on or off.
Sorry for the late addition. I saw your post before my holidays in office and forgot to respond.
In fact the name 'Simple' really is already taken by Remi Coulom for his simple chess engine. It is still available for download as a part of this package: http://www.remi-coulom.fr/chess-0057.tar.bz2
IIRC he once asked for not including it in tournaments but I might be mixing it up with another one.
A part of the readme for the version I still have here:
This is a release of my simple chess engine. It is intended as a way to share
my newly implemented treemap visualisation tool with other programmers. I did
not take a long time to document it very cleanly, so do not hesitate to e-mail
me any question if you have one. Here is a short description of the files you
should find in this archive:
simple.exe is the binary of the simple chess program
...
version 0048, Copyright (C) 1997-2001 Remi Coulom
The relevant entry in my RWBC chronology pages, though extremely out of date still useful for some researches I guess.
(May be I will really start an update if I am in the mood)
OK, thanks. I guess I have to go for a somewhat less-obvious name, then. 'King Slayer' sounds good, I hope that is still free.
BTW, it proves indeed surprisingly difficult to write something simple that does crush Fairy-Max. I though that having real PST and more serious move sorting (real MVV/LVA and killer heuristic, rather than only slipping the IID/hash move in front) would have done it. But even with some King-Shelter code it was only scoring ~77% against Fairy-Max. And Joker beats it by a similar score. And when I switch on more eval features, like passer evaluation similar to what Joker has, Joker totally crushes it.
The problem seems to be the search depth: Joker searches 2-3 ply deeper. This is a bit surprising, as the search was not supposed to be very different from that of Joker (same null move, same LMR, same check extension). The only difference I am aware off is the sorting of captures; Joker uses SEE for that, the new engine used strict MVV/LVA.
