Lucas Braesch

Joined: 31 May 2010 Posts: 1730
|
Post subject: Re: Quick steps on the dancefloor (2): Discocheck 3.6 Posted: Sat Jun 30, 2012 9:57 am |
|
|
| Mike S. wrote: |
- The engines had some Nalimov support, IOW if a 4-piece ending, or a 5-piece ending with R-R or Q-Q was reached, the interface finished the game from the tables. I did not investigate if one engine may have benefit more from that, than the other.
|
Even 5 men tablebase add virtually zero elo, contrary to what people tend to think. However, they make some endgames look cleaner and more precise. But in most cases the result of the game is the same with or without. Cases where EGTB actually help are very rare, and to compensate for that benefit, they slow down the search and take a lot of RAM. Anyway, DiscoCheck does not use tablebases (except for a built in bitbase generated at runtime, for the KPK endgame). From what I see in the command line, Texel does not use EGTB either. So the impact of this is really zero (unless the GUI plays the endgame instead of the engines, when a 5 men or less is reached).
| Mike S. wrote: |
- In one game each, the engines stopped working for reasons unclear, thus losing on time. The match continued normally. No time losses otherwise.
|
I've played tens of thousands of games with DiscoCheck without a single crash, and I've never seen Texel crash either. I'm using cutechess-cli on linux: it's a nerdy command line tool, but it's very fast and a lot more reliable than any GUI. Also, it allows me to play games in parralel: since both engines are using one thread only, and I have 2 CPU, I can safely play 2 games in // all the time, and divide the time of testing by 2 (though if you use a laptop, I hope for your sake that you have a good fan).
As for time losses, cutechess-cli allows me to set a tolerence. I typically use sth like 100ms, accounting for delay in the GUI, from the system load (other apps running) or internal I/O and processing of commands, and also the time spent between two polls (DC looks at the clock only every 512 nodes searched). Above such a small margin, I consider that the engine is at fault, and it deserves to loose  |
|