Daniel Shawul wrote:A bug i have yet to fix is the multicore version that hangs sometimes.
I can confirm this bug. In the mini-gauntlet posted above at least four games had to be replayed and replaced because Scorpio's "connection stalled" (in Cute Chess' terminology).
Daniel Shawul wrote:About its strength, It should be more or less same strength as scorpio 2.8 if you set treeht=0. See for example the test i gave
here.
Code: Select all
Finished game 37 (scorpio vs scorpio-mcts): 1-0 {Black resigns}
Score of scorpio vs scorpio-mcts: 12 - 10 - 15 [0.527] 37
However, this is meaningless because mcts is used only at the root and its children.
Yes, I read that part. You also stated earlier that you would like to see
treeht values > 0 tested, hence my tests.
Daniel Shawul wrote:With other values of treeht=128 or so, you have to use a longer time control so that the standard alpha-beta search at the leaves is triggered enough.
That's what I figured as well. At this stage MCTS would probably be too slow for blitz tests. Would you consider a 40/40 repeating time control long enough for our purposes? That would actually be something like 40/20 or 40/22 (adapted for CCRL), anything longer would not be eligible for CCRL; although I wouldn't mind doing a private test or two since the MCTS concept looks very interesting.
Daniel Shawul wrote:I would very much appreciate it if you can test these settings a. If so, let me know if you need the latest exes i have with negascout and the one that spends only 30% in growing the tree.
In the tests mentioned above I used the updated Scorpio 2.8 dated Feb 12, CRC32=4486111A. If you prefer I use other/newer execs please PM me the links (if you don't want to release them publicly). Also please post the exact settings I should use in my tests, it's not clear from your previous post what they should be.
I'd be glad if I could help to improve Scorpio's MCTS, as no other engine that I'm aware of is doing something like that.
Got a question about Scorpio 5-men EGBBs in the meantime. I experience unusually long load times in Cute Chess GUI when I have
egbb_load_type set to 3 - a little over two minutes when reading off an SSD, and -- the worst scenario -- around five minutes when playing two Scorpio versions vs. each other
and reading off a HDD (the E5-2690v2 has no SSD yet, but the HDD is a fast 10K one). Is it a problem with Cute Chess or do I have something misconfigured? For the tests mentioned above I had to change egbb_load_type to 1; the EGBB load times went down to 3 seconds, but I'd rather have Scorpio use 5-men EGBBs, of course. I don't think that egbb_cache_size set to 32 is the problem, all of my test boxes have at least 32 GB of RAM and even with 4CPU gauntlets running memory usage rarely exceeds 40% on any of them, according to the Task Manager (Win 7 x64 Pro on all three, BTW).
