Author: Mikael Bäckman
Date: 14:18:43 05/13/03
Go up one level in this thread
On May 13, 2003 at 15:24:21, Matthias Gemuh wrote:
>On May 13, 2003 at 13:15:30, Mikael Bäckman wrote:
>
>>Hi,
>>
>>I'm trying to reduce qsearch tree size in my engine. I've had many odd looking
>>results (from 10% to 99%), some of which I've tracked down to bugs in
>>nodecounting (maybe!).
>>
>>Where is the proper place to update the node counts? A, B, C, D or E?
>>
>>In the below code, A and B is of course replaced with "nodes++" and C, D, E with
>>"qnodes++";
>>
>>And of course the code is incorrect, only the placement of A, B, C, D and E
>>matters here.
>>
>>
>>int alphaBeta(int alpha, int beta, int depth)
>>{
>> /* A */
>> if (depth < 0) {
>> score = qsearch();
>> return score;
>> }
>> /* B */
>> nMoves = genAllMoves();
>> while (i < nMoves) {
>> makeMove(move[i]);
>> score = alphaBeta(-beta, -alpha, depth - 1);
>> unMakeMove(move[i++]);
>> }
>>}
>>
>>
>>int qsearch(int alpha, int beta)
>>{
>> /* C */
>> score = evaluate();
>> if (score > alpha) {
>> if (score > beta) return score;
>> alpha = score;
>> }
>> /* D */
>> nMoves = genAllCaptureMoves();
>> while (i < nMoves) {
>> makeMove(move[i]);
>> /* E */
>> score = qsearch(-beta, -alpha);
>> unMakeMove(move[i++]);
>> }
>>}
>>
>>
>>
>>Thanks,
>>
>>Mikael
>
>
>
>I do A+C and get C/(A+C) = 50% (approx.), but my engine is very weak.
>
>/Matthias.
I currently use A and E. The reason I asked this was because I had way too few
qnodes compared to what others have posted.
I guess most use A and C. I will change to that too.
My engine is a newbie-engine-coded-from-scratch-with-a-million-bugs which
currently doesn't do any extensions nor internal iterative deepening.
It doesn't have a name either, maybe I should call it NECFSWAMB? :)
For the other beginners out there, here's my testdata.
I ran a bunch of 6-ply tests on the Bratko-Kopec positions with counters at A
and E.
1. No sorting other than pieceSquare values.
Test aborted after 30 minutes.. only four positions done..
2. pv, mvvlva
Time: 300.33 Speed: 383 kNPS
Nodes: 114934493 Qnodes: 66.3%
3. pv, "futile captures" removed in qsearch, mvvlva
Time: 201.97 Speed: 310 kNPS
Nodes: 62647078 Qnodes: 38.9%
4. pv, SEE
Time: 237.19 Speed: 212 kNPS <-- Brute forcish SEE steals 1/3
Nodes: 50399894 Qnodes: 24.9%
5. pv, SEE, killers
Time: 137.67 Speed: 199 kNPS
Nodes: 27432574 Qnodes: 29.0%
6. pv, SEE, killers, hash
Time: 108.05 Speed: 189 kNPS
Nodes: 20423703 Qnodes: 29.1%
Hash: 3.26%
7. pv, SEE, killers, hash, nullmove
Time: 65.54 Speed: 202 kNPS
Nodes: 13234251 Qnodes: 24.7%
Hash: 1.52%
Here I switched to updating the nodecounts at A and C.
(knps is back at 300. what an optimization :) )
8. pv, SEE, killers, hash, nullmove
Time: 60.39 Speed: 315 kNPS
Nodes: 19079796 Qnodes: 53.2%
Hash: 1.59%
9. (8-ply) pv, SEE, killers, hash, nullmove
Time: 911.15 Speed: 286 kNPS
Nodes: 2060658973 Qnodes: 53.8%
Hash: 3.12%
This suggests that the problem is in hashhit % not qsearch %..
Thanks,
Mikael
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.