Not logged inRybka Chess Community Forum
Up Topic The Rybka Lounge / Computer Chess / Why does knowledge slow down the search in chess engines?
- - By rocket (****) Date 2020-04-29 10:03
The evaluation parameters are already predetermined to every conceivable position. So say for example: pawn center gives an output of 0.2, king safety, 0.5. All of this gets interpolated with the current position in a purely mathematical way and a resultng PV results.

When the calculations occur and everything gets interpolated, why does engine with more parameters search slower? The actual lines examined will take the same amount of time anyway. And the interpolation will occur just as fast as me typing in 2+2....
Parent - - By MrKris (***) Date 2020-04-29 13:16
Sorry, I am not a programmer (but know a little about it).

> why does engine with more parameters search slower?

Because each core/thread in a CPU can only execute one instruction at a time and the more parameters the more instructions and so the longer time to execute them.

It sounds to me like you are confusing RAM (the Stockfish program for example) + CPU with 'hard wired' (old fashioned term) circuitry in the CPU.

It is not:
INPUT to circuitry in the chip (the more the faster) to OUTPUT.
{Like the better 'bigger' floating-point-units in newer CPU's vs. the basic 'small' early ones.}
This situation reminds me of your "interpolated":

> All of this gets interpolated with the current position

Stockfish/knowledge instructions do not get 'put in the CPU' in any sort of circuitry/"same amount of time" way,

> will take the same amount of time anyway.

Maybe, only if a custom chess-chip (instead of a general purpose CPU) could be made with millions of transistors for every chess function.
_ _ _ _ _ _

It is: each of the cores/threads in a CPU can only execute one extremely simple instruction at a time, always:
instruction 1 (of very, very, many forming Stockfish/"parameters")
instruction 2
instruction 1,000,000
All of the instructions (such as 'if square x = 0 (blank) skip the next part' is several instructions) are executed for each and every position/node.
Parent - - By rocket (****) Date 2020-04-29 17:26
Hmm.. i don't get it. The entire eval function is contained within a move no matter if it's 1 sec ponder time or 30 sec.

So... when you say one thing at a time, the move generated must contain all of it regardless.
Parent - By MrKris (***) Date 2020-04-29 20:57
Sorry, I probably do not know what you mean in your original post.

Here is from
Author: xoto10
Date: Thu Apr 16 21:40:06 2020 +0200
Timestamp: 1587066006

Scale factor in opposite-color bishop endings ...

The change is here:

Just one of very many knowledge features.
Both the old version (red) and new version (green) of "if (   pos.opposite_bishops()" are instructions that take take time for each (more or less) of the millions of nodes per second.

Less knowledge without either would be faster, knowledge with either takes time and is slower, fewer nps (not so much individually but in total for all the knowledge/features).
Parent - - By Labyrinth (*****) Date 2020-04-29 23:34

>why does engine with more parameters search slower?

Why wouldn't it? More parameters means more instructions which means more work.
Parent - - By rocket (****) Date 2020-04-29 23:40
The evaluation function has formulas for different types of positions programmed in advance, so why would it matter how much parameters there are if the math is already settled?
Parent - - By MrKris (***) Date 2020-04-30 08:22

> The evaluation function has formulas for different types of positions programmed in advance, so why would it matter how much parameters there are if the math is already settled?

If you like, maybe explain what you mean by:

> formulas for different types of positions programmed in advance

{As in evaluation.cpp ?}


> parameters

Parent - By rocket (****) Date 2020-04-30 23:04
By that I mean the evaluation score for each position.This works  in principle exactly  the same as material trade scores :"sum of all values..."
Parent - - By Uly (Gold) Date 2020-04-30 23:33 Upvotes 1

> The evaluation function has formulas for different types of positions programmed in advance, so why would it matter how much parameters there are if the math is already settled?

Because you need a "formula" for each parameter, and each "formula" requires "time".

Suppose that you have a "formula" that adds a possible evaluation to positions where a queen and rook are on a 7th rank. Now the engine for each position has to check if there's a queen and a rook on the seventh rank, and decide if it adds the bonus or not. This is costly.

If actually this bonus is good, when two distant positions evaluate the same, but one has a queen and a rook on the 7th rank, the bonus makes the engine aim for it, so you have added "knowledge" that those positions are preferable to other positions.

If this new knowledge adds 0.09 elo points, but the engine is slowed down by having to check if there's a queen and rook on the seventh rank, and this slowdown makes the engine 0.1 elo weaker, then it's not worth it, and you'd rather have an engine that has this knowledge missing, but it's faster.

It's the same for all kinds of knowledge, the more "formulas", the less nodes analyzed, so you can only afford to have knowledge that slows the engine but pays off by increasing the quality of positions analyzed beyond the elo you have to pay for it.
Parent - - By user923005 (****) Date 2020-04-30 23:44 Upvotes 1
This is correct and it has an ugly, nasty side effect.
Engine developers test parameters at hyper-bullet time control.
If, during testing, an evaluation feature takes so much energy to calculate that the Elo score drops, the feature is usually left off.
Sound unimportant?  Many engine programmers simply left off under-promotion for their engines because it cost Elo.
Or they may have allowed under-promotion to knight only and no under-promotion to bishop or rook.
The side effect of this is that such engines will not and cannot, even with infinite time, find a key move that involves and under-promotion anywhere in the pv.
Of course, this is just one example.
Another one is draw detection.  If someone is behind in material and building a pawn wall, most engines will not see it until it is too late and the wall is finished.
That's because (you guessed it) it cost Elo.

Now, there are some of us who are not in a big, foaming-mouthed hurry.  We want the correct answer, no matter what it costs and will wait a bit longer to get it.
For this reason, I think it would be good if the analyze command were implemented differently than the go command.
If I ask for analysis, I don't want any 2 Elo shortcuts that remove vital features from the evaluation.

But I am in a minority.  A voice calling in the wilderness without an ear to hear.  And if they hear by some chance, they simply shrug.
Parent - By Uly (Gold) Date 2020-05-02 02:03 Upvotes 1
I liked Rebel's (Pro Deo / Benjamin) solution for this.

It had a Chess Knowledge personality parameter, not unlike the "Contempt" parameter in today's engines. The difference is that it allowed you to adjust for this. Want a dumber, faster engine? Set it down. Want an engine with all the knowledge that finds the truth in a position and you don't care about the cost? Increase it, it goes up to 500!

Something funny was that 100 was the default, but it turned out that some of that knowledge was actually worth the slowdown, so 125 became the default.

If this is the engine you're looking for then the question is how much are you willing to wait? By 50 elo per doubling 1 minute of Stockfish 11 is equivalent to some 65536 minutes of Rebel, or about 1000 hours to see if it sees a move Stockfish will never find...
Parent - - By h.g.muller (****) Date 2020-05-10 14:25

> The evaluation function has formulas for different types of positions programmed in advance, so why would it matter how much parameters there are if the math is already settled?

What you don't seem to understand here is that programming is not the same as executing a program. The formulas are programmed in advance, but the outcome of those still has to be calculated when the program runs. Because the outcome depends on the position to which you apply them, (otherwise they would not be frmulas, they would just be constants), and this was not known in advance.
Parent - - By rocket (****) Date 2020-05-10 20:16
Sure but if there is a forced winning line, why would it take longer to identify the move with a heavy knowledge engine as opposed to a pure brute force engine? I'm not saying it has to take longer, just that the general rule is that it takes longer...

What exactly gets in the way? The lines branch out and get's examined anyway, and a forced win does not get more muddy just because the engine "knows" more (unless there's really buggy knowledge implementation).
Parent - - By user923005 (****) Date 2020-05-10 21:56
Let's do a mind experiment, with chess engines A and B.

Chess engine A only counts wood.  It does not understand passed pawns or mobility or bishop pairs or any other chess feature.  It knows wood.  I am up a pawn, I am ahead.

Chess engine B has 10,000 features.  It knows about all sorts of things like edge pawns being worth less in the opening and more in the endgame.  And it even knows by exactly how much.

Now, counting wood is pretty easy.  32 chessmen max, 2 chessmen min.  And you don't bother to count the kings.
On the other hand, evaluating 10,000 features takes some serious time.  Does ten thousand features sound absurd?  That may be the number of features NN programs examine.

So now pretend it is you.  You have two exercises for some random board position.  Count the wood.  You can do that pretty fast, right?  We humans can do that almost without thinking.  But now, look at and evaluate the material imbalance.  Does either side have a bishop pair?  Are there any outposts?  Is there any Alekhine's gun type pieces backing one another?  Can I generate one?  How is my mobility? Can I undermine? Do I have or can I get a rook on an open file?  Let's keep going this way until 10,000 features are exhausted.

Can you count the wood faster or count the 10,000 features faster?

You have an advantage that the computer does not have.  You can stop counting when you find something important.  But the computer has to keep going because it doesn't actually *know* anything.  It is just a brute machine, going through a list of instructions it has been given to examine.

Now, a second question.  Which player will make the better moves, the  one who counts wood or the one who considers a whole pile of features?
Parent - - By bob (Gold) Date 2020-05-15 01:43
Answer to second question.  If you can see deep enough, the wood-counter wins.  If you can see even deeper, you don't even have to count wood, just recognize someone has been mated.

Evaluation is simply an approximation used because a chess program can never get to "the truth" from early opening positions.  So it needs something to guide it along, hopefully leading to a winning position.
Parent - - By Uly (Gold) Date 2020-05-15 21:17

> If you can see deep enough, the wood-counter wins.

I've never seen this in practice. In my experiments very low depth from a normal engine was enough to beat the wood counter with very high depth EVERY SINGLE TIME, and the wood counter's moves would seem random, and would wrongly think it's winning just because its losing positions were high on material. No matter the depth, chess's horizon is so big that all it could see was it was up on material on a distant position, and aim for it, even if it was getting mated in 2 moves (more depth would just push the mate beyond the horizon in different variations).

The only entity I saw losing against the wood-counter was the "eval only" engine that had all material as 0. Bizarre games where it seemed as if one side was an expert grandmaster against someone on their first game, yet somehow the patzer that made random pawn moves would end up with material advantage that was decisive.
Parent - - By user923005 (****) Date 2020-05-15 21:54
I think Dr. Hyatt's point was a theoretical one.  If you search so fast you see to the end of the game (and chess is finite) then the game is over.  Now, pragmatically, it's not a good idea because it will make lots of bad moves if only counting wood and does not search deep enough to see a conclusion.

But I think that the general idea has some interesting aspects.  Consider a chess engine that only knows 3 things:
1) Game is won
2) Game is drawn
3) Game is not yet decided
Basically, what we are really talking about is a move generator, in some  sense (because a move generator has to know these 3 things).
Now, there is a logical search called and/or search that can take simple things like above and use probability to do pruning.

As you know, there are an awful lot of chess moves, so it seems problematic to use this method.  But this GPU move generator: can do perft 11 in one hour on a GTX 700.  So on modern equipment it might be able to do perft 10 in a minute.  Now, with and/or search pruning, it might be able to get very deep indeed.  And with new technology GPUs, it might eventually become feasible to see clear to the endgame.  So, the world's dumbest eval might be enough to have the best possible outcome, literally optimal.  How's that for strange?
Parent - - By Labyrinth (*****) Date 2020-05-15 23:42

>GPU move generator

Is that Linux only? Any chance you could send a windows binary if not? I'd like to try it on my 2080S : p
Parent - By user923005 (****) Date 2020-05-16 04:39
I think if you have the NVIDIA SDK and msys2 it will probably build on windows, but i did not try it yet
Up Topic The Rybka Lounge / Computer Chess / Why does knowledge slow down the search in chess engines?

Powered by mwForum 2.27.4 © 1999-2012 Markus Wichitill