Going fast

[Michael Sherwin]

The qsearch with it's calls to eval seems to be where a program spends the most time. So I suggest.

1.) move as much of the eval to just before the qsearch as possible.

2.) implement a 'short circuit' qsearch. If a capture is likely, as it is being generated, to cause a cut then make it immediately. If a cut is indeed the result then all the captures need not be generated.

Have either of these been done before? Concidered?

[Bill Rogers]

I may be wrong on this but I thought you only implemented qsearch if and when a piece was captured or an incheck was found. I can see no other reason to use it. The two mentioned items leave a non quite position and I was under the impression that is why qsearce was made so it might find a quiter ending if possible.
Bill

[Guetti]

I may be wrong on this but I thought you only implemented qsearch if and when a piece was captured or an incheck was found. I can see no other reason to use it. The two mentioned items leave a non quite position and I was under the impression that is why qsearce was made so it might find a quiter ending if possible.
Bill

I'm not sure I understand you right. You say if I move my queen to a square attacked by the enemy at the very end of my search that would be a quiet position?
In my understanding qsearch is called at the end (leafs) of every search.

[Uri Blass]

The qsearch with it's calls to eval seems to be where a program spends the most time. So I suggest.

1.) move as much of the eval to just before the qsearch as possible.

2.) implement a 'short circuit' qsearch. If a capture is likely, as it is being generated, to cause a cut then make it immediately. If a cut is indeed the result then all the captures need not be generated.

Have either of these been done before? Concidered?

I am not sure if 2 is going to save a lot of time because I think that in most of the cases the time is spent in finding that there are no good captures and not in generating irrelevant captures.

I am not sure what you mean exactly by 1
Normal qsearch start with evaluate so what do you mean by
"move as much of the eval to just before the qsearch as possible"?

[Uri Blass]

I may be wrong on this but I thought you only implemented qsearch if and when a piece was captured or an incheck was found. I can see no other reason to use it. The two mentioned items leave a non quite position and I was under the impression that is why qsearce was made so it might find a quiter ending if possible.
Bill

I'm not sure I understand you right. You say if I move my queen to a square attacked by the enemy at the very end of my search that would be a quiet position?
In my understanding qsearch is called at the end (leafs) of every search.

Your understanding is correct

Note only that in many cases the first evaluate in the qsearch cause a cutoff so you do not need even to generate captures.

Uri

[Harald]

Note only that in many cases the first evaluate in the qsearch cause a cutoff so you do not need even to generate captures.

Uri

Here I would like to read some arguments or opinions because I am not sure
what is the best strategy. What is cheaper, evaluation or q-search?

- If I have a big evaluation only without shortcut or lazy evaluation I have
to do it somewhere in the qsearch, before the first move or in deeper
plies also. It should be done before the moves and can be used as a
stand pat value.

- If I have a two part evaluation considering material (and easy big terms) first,
I could do it before each q-search and find a lazy cut-off without doing
the rest of the evaluation. If I do not find a lazy cut-off I do the rest of
the evaluation before trying some moves. With this I have a second
opportunity for a stand pat cut. If this does not help I have to try the (capture) moves.

- If I have a two part evaluation considering material (and easy big terms) first,
I could try to wait with the evaluation and find some captures first,
that go out of the alpha-beta window. Perhaps like this:
-- Is the material (and easy big terms) too extreme for alpha-beta? Cut.
-- Else find big evaluation terms and margins for the deeper q-search.
-- Do a deeper q-search (good winning captures, checks?) There may be cuts.
-- Do the rest of the evaluation now and use it as a stand pat value.

Is it important to tune the evaluation and q-search like that or is it just nonsense?
Is it worth the effort?

Harald

[Harald Johnsen]

The qsearch with it's calls to eval seems to be where a program spends the most time. So I suggest.

1.) move as much of the eval to just before the qsearch as possible.

2.) implement a 'short circuit' qsearch. If a capture is likely, as it is being generated, to cause a cut then make it immediately. If a cut is indeed the result then all the captures need not be generated.

Have either of these been done before? Concidered?

How can a capture cause a cutoff ?
After that capture you must look at the opponent captures, there is no short cut here.
If you are thinking at the cut off (eval() >= beta) at the begining of the recursive call to qs then we have indeed :
if( eval() >= beta)
return eval();
this is equivalent to :
if( -(previous_eval + capture) >= -alpha)
return -(previous_eval + capture)
and this is allready done in the caller code :
if( (previous_eval + capture) <= alpha)
continue;

So if (previous_eval + capture) >= alpha) then the cut off at the recursive call to QS will not be true and you must look at the opponent captures.

HJ.

[Harald Johnsen]

The qsearch with it's calls to eval seems to be where a program spends the most time. So I suggest.

1.) move as much of the eval to just before the qsearch as possible.

You mean material will be the quick part and positional the slow part. So you only update the material part inside the QS.
This is difficult to handle. One problem is that the eval returned by qs will be accurate only when you stand pat. If there is winning captures then the eval will lack the positional value, perhaps this is enought for a cutt off but you can not store this crapy eval in your hash table.
The other problem is that material does not mean anything in lot of positions (not only in end games), so your scores will be really wrong (king safety, pawns on 7th, etc).

HJ.

[Michael Sherwin]

The qsearch with it's calls to eval seems to be where a program spends the most time. So I suggest.

1.) move as much of the eval to just before the qsearch as possible.

You mean material will be the quick part and positional the slow part. So you only update the material part inside the QS.
This is difficult to handle. One problem is that the eval returned by qs will be accurate only when you stand pat. If there is winning captures then the eval will lack the positional value, perhaps this is enought for a cutt off but you can not store this crapy eval in your hash table.
The other problem is that material does not mean anything in lot of positions (not only in end games), so your scores will be really wrong (king safety, pawns on 7th, etc).

HJ.

RomiChess already does this (1.), as the only thing in Romi's eval function is pawn structure code (hashed) and the two bishop bonus.

All other eval terms are precomputed at the root and placed in piece-square tables.

So, putting part of the eval just before the qsearch is certainly possible.

Concerning my second point (2.). If PxQ is possible and it is found early the capture can then just be made and -qsearch called. If when returning from -qsearch with a score >= beta then no more captures need to be generated. Simple really, but, will there be a speed gain?

[Uri Blass]

The qsearch with it's calls to eval seems to be where a program spends the most time. So I suggest.

1.) move as much of the eval to just before the qsearch as possible.

You mean material will be the quick part and positional the slow part. So you only update the material part inside the QS.
This is difficult to handle. One problem is that the eval returned by qs will be accurate only when you stand pat. If there is winning captures then the eval will lack the positional value, perhaps this is enought for a cutt off but you can not store this crapy eval in your hash table.
The other problem is that material does not mean anything in lot of positions (not only in end games), so your scores will be really wrong (king safety, pawns on 7th, etc).

HJ.

RomiChess already does this (1.), as the only thing in Romi's eval function is pawn structure code (hashed) and the two bishop bonus.

All other eval terms are precomputed at the root and placed in piece-square tables.

So, putting part of the eval just before the qsearch is certainly possible.

Concerning my second point (2.). If PxQ is possible and it is found early the capture can then just be made and -qsearch called. If when returning from -qsearch with a score >= beta then no more captures need to be generated. Simple really, but, will there be a speed gain?

I think that in this case idea 1 is already used in old commercial programs like Fritz5.32 or Genius

It is called preprocessing and it is not a good idea.
Fritz improved after it stopped to use this idea.

Note that this idea is bad not only for playing strength but also for analysis.

old Fritz or Genius could trade queens and see advantage for white before the trade when they see no advantage for white after the trade.

Uri