FGRL 60 sec + 0.6 sec Rating list - Komodo 11.2

[mjlef]

Komodo does scale opposite color bishop endings and ppxxx vs pxxx endings. I have not compared how much we scale by compared with Stockfish, but I assure you it is in there.

I did not include the bit board code in Komodo or Stockfish in my line counts since it is not part of the regular eval. Including the Komodo equivalent would greatly increase the K linecount.. And only a small part of types.h is eval related, although I see Stockfish puts piece values in there. You are right endgame file should have been included. Counting the same the ratio would be more than 2 to 1.

I did not include bitboard.cpp, which is very large in SF too, but bitbase.cpp, which is another thing.

well, somehow I don't quite unerstand that: one the one hand you would not claim Komodo has more terms than SF, on the other you still insists line count is more than 2/1.

really difficult for me to make precisely sense of what is going on, but maybe it is better to leave things like that now, anyway Komodo is not public domain and you reserve the right to reveal or not sensitive information.

[d]8/5kp1/4r3/2R5/5PP1/6K1/8/8 w - - 0 1

Komodo: +100cps, looks like not scaling this

Komodo has a kind of KPK database in it, which is like the rules Stockfish uses to generate the same information that is in bitbase.cpp. So I left them both out. Komodo's version had both data and code, which would unfairly increase the line count for Komodo. So I left it off of both of them. I could recount with them if you want but the ratio would increase.

types.h has almost no eval code in it (just the piece values for opening and endgame, whihc is just a couple of lines). The rest is general function prototypes and definitions used more in the move generator and search than in the eval. So that is why I did not include it.

Mark

I see types.h including more eval-related stuff than otherwise.

enum rank, enum file, enum scale_factor, enum phase, enum piece, enum score, enum castling, enum castling right...

also, most inline functions, inline fileof(square s), inline colourof(piece pc), relative rank(colour c, piece pc)...

so, basically, should be included.

I don't know why you want to make it a factor of more than 2, when this would contradict a couple of related conditions.

piece values, scale factor stuff and phase is eval. all the other stuff is support code used in both the move generator and search, so I did not include them in either Komodo or Stockfish line counts. If you are going to include that in the Stockfish line count for eval, a similar number of lines would need to be added to Komodo. In general, types.h should define the types of variables/structures used. I find putting basic piece values in there a bit strange. Doubtless, Stockfish programmers would find a lot of things in Komodo strange too.

If I included some tables used in the eval defined elsewhere in Komodo, the line count of the eval would grow again. When you talked about the eval, I assume you mean code that actually calculates the evaluation. This is a lot bigger in Komodo than in Stockfish. In Komodo, this code is in a file named pop.cpp. Special evaluations for some endgames, table filling code and the like is in eval.cpp and elsewhere. The code that is run on 99.9% of the positions searched is in pop.cpp, and that is simply much bigger than in Stockfish. But we do this in a way that does not take up a lot more time than Stockfish. Comparing like nodes and dropping lazy eval from the programs, and Komodo gets around 16% less nodes per second. The reason it is not worse, is Komodo uses precomputed values, caches more information, and has I think a slightly faster magic multiplication system than Stockfish uses. Of course, Stockfish's PEXT based sweep attacks is faster still. I should write that one day, but I want to see if I can find a way to do it so it is autodetected, so users do not need a =to pick the right version.

[mjlef]

Komodo uses a form of Lazy Eval that helps speedup its node rate. I think the development versions of Stockfish have Lazy Eval, but the version I saw them using when I checked a month or so ago was less aggressive than what we do in Komodo. I cannot say exactly how much "bigger" Komodo's eval is, but the code is much larger, and it has a lot more terms. I am not claiming bigger is better though.

I never said we have more evaluation terms than Stockfish. I have not tried to count them. But Larry and I try to keep the number of terms low, since it is hard to tune a huge number or terms. We rarely do much tuning. Automated tuning has not helped the last few times we try. So we try a few values for a new term and keep whatever tests best.

I'm not sure how to combine the two statements you made (bolded by me).

You are right. In one case I was using terms to indicate amount of things measured. In the second, I meant actual different numbers. More subdivisions of the knowledge. We try to keep the number of terms (numbers) as low as we can, as does Stockfish. If "terms" means conditions that are measured, then Komodo has more. If it means different actual numbers, it would be closer. I can try and make a count when I have time. I will amend my claim and try to avoid using the word "terms".

[petero2]

Komodo uses a form of Lazy Eval that helps speedup its node rate. I think the development versions of Stockfish have Lazy Eval, but the version I saw them using when I checked a month or so ago was less aggressive than what we do in Komodo. I cannot say exactly how much "bigger" Komodo's eval is, but the code is much larger, and it has a lot more terms. I am not claiming bigger is better though.

I never said we have more evaluation terms than Stockfish. I have not tried to count them. But Larry and I try to keep the number of terms low, since it is hard to tune a huge number or terms. We rarely do much tuning. Automated tuning has not helped the last few times we try. So we try a few values for a new term and keep whatever tests best.

I'm not sure how to combine the two statements you made (bolded by me).

You are right. In one case I was using terms to indicate amount of things measured. In the second, I meant actual different numbers. More subdivisions of the knowledge. We try to keep the number of terms (numbers) as low as we can, as does Stockfish. If "terms" means conditions that are measured, then Komodo has more. If it means different actual numbers, it would be closer. I can try and make a count when I have time. I will amend my claim and try to avoid using the word "terms".

I see, thanks for the clarification.