How long should each call to qsearch take?

[jordanbray]

I've been working on texel's tuning method for my engine, and have amassed 258,000 unique grandmaster games for tuning.

This resulted in 14,274,000 unique positions. It takes about 67 seconds to go through all those, but that seems a bit long to me.

(Oddly enough, I had it running much faster earlier, but I'm not exactly sure what I broke. All I believe I did was fix stuff.)

Anyways, I was wondering if this seemed slow to anyone else, so I can decide if I need to reduce the number of boards, or speed up the qsearch.

Thanks.

[jorose]

For what it is worth you are significantly faster than I am. Mine takes around 60 seconds per million positions on my 2.5 ghz dualcore notebook. I have a Java project that runs an instance of my c++ engine as a separate process in order to keep tuning code somewhat modular and separate from my main engine code however, so that is probably slowing me down somewhat.

As a side note you might want to download CCRLs 40/40 or 4/40 game lists to increase the size of your database. That way you can reduce the amount of positions you take per game which should result in better tuning imo.

[jordanbray]

I should probably mention that it isn't quite as significant as it sounds, because I am using 8 threads on an 8 core machine.

[jordanbray]

(Oddly enough, I had it running much faster earlier, but I'm not exactly sure what I broke. All I believe I did was fix stuff.)

In case anyone is curious, I did find the source of this issue, which got the time down to 21 seconds (which is on par with where I was before).

This is with TT, move ordering, futility pruning, evasion pruning, good SEE values, no checks, and 8 cores.

The bug was related to some changes I made in my move ordering, which caused a huge overhead in getting the next move.

Still, I think I'll need to remove some positions before I can get any useful values from texel. I'm using the GSL library to actually handle finding a local minimum, and it calls my evaluation (of the scores) quite a few times.

[bob]

I've been working on texel's tuning method for my engine, and have amassed 258,000 unique grandmaster games for tuning.

This resulted in 14,274,000 unique positions. It takes about 67 seconds to go through all those, but that seems a bit long to me.

(Oddly enough, I had it running much faster earlier, but I'm not exactly sure what I broke. All I believe I did was fix stuff.)

Anyways, I was wondering if this seemed slow to anyone else, so I can decide if I need to reduce the number of boards, or speed up the qsearch.

Thanks.

You are talking about a real call to Quiesce() which means multiple evaluation calls and recursive Quiesce() calls? Best answer would be to sum the total nodes searched and divide by 67, and see if that NPS seems reasonable. Some positions likely produce a call to evaluation and a return. Others might blow up into hundreds or thousands (or much more) depending on your quiescence rules. Do you do checks? How many plies of checks? Do you do full-width escape from checks? Do you do lazy eval? (and if so, do you pass in +/- infinity for this test or something else?) Etc

[jordanbray]

Best answer would be to sum the total nodes searched and divide by 67, and see if that NPS seems reasonable. Some positions likely produce a call to evaluation and a return.

OUCH!

The number of nodes searched seems preposterously low, with the total being 57 million, so I'm glad I did that. That is 4.04 nodes per position. I cannot imagine that being correct. Maybe it is, but that seems a bit ridiculous.

I do, in fact do a lot of pruning there, with evasion pruning, futility pruning, good see values, etc, but this seems ridiculous.

Either my move ordering is amazing, or something else is seriously wrong. Thanks for the advice.

I answered your other questions about the nature of the qsearch in another post, if you are curious.

EDIT: On the other hand, I wonder how many TT hits there are? So many of these positions are from the same game, and I have ensured that the qsearch is called for each position in each game before moving to the next one. Still, very strange results.

Double Edit: To answer your question directly, I got the runtime down to 21 seconds, which puts the search at 2.7 mil nodes/sec. I have absolutely nothing to compare that to. Per core that works out to 337 thousand per second. That can't be good