PVS & Embla

[Sven]

Possibly yes, but I have no idea where.
Note that the movegen is a bit slow, that doesn't help either.

Is there a simple way to compile Embla under Windows using MinGW or MinGW64? I tried but failed even after uncommenting some Linux-specific pieces of code ...

Regarding your move generation, I think it is not inherently slow. But I see two issues that very likely slow down your engine IMO:

1) My old review comment that I made several times already You generate moves for both sides, only to be prepared for a later mobility calculation during static eval. But:

- Mobility does not involve king or pawn moves, so you go through both move lists again during mobility calculation and exclude these, counting all others. That is a lot of wasted effort.
- The effort for storing the opponent's moves in memory, instead of only counting them, is totally wasted, not mentioning the extra effort for the most complex part of move generation which is generating pawn moves.
- And in many cases you don't even call the static eval during search so that mobility will not be calculated.

2) You use the same move generator for full-width search and for quiescence search. So in QS you go through the move list and remove all quiet moves which is a lot of effort. You'd better use a separate move generator for captures and promotions (after fixing mobility calculation as mentioned above).

[Sven]

Furthermore I recommend to avoid using "goto" (you do it in your PVS code)

Apart from that, the PVS implementation seems to be ok. My only remark is that I would prefer to set "bSearchPV = false" immediately after undoMove(). Not doing so might cause to search with a full window more than once without being forced to, which could explain why the PVS version plays weaker. CPW recommends that as well in a footnote of the PVS pseudocode.

[AlvaroBegue]

Furthermore I recommend to avoid using "goto" (you do it in your PVS code)

My own implementation of PVS is quite different but also uses goto. There's nothing wrong with that. There are cases where the goto more clearly expresses what you want the code to do than the alternatives.

[tttony]

You can change:

Code: Select all

if (bSearchPV)

to: (I guess that the mn variable counts the legal moves)

Code: Select all

if (mn == 0)

Also I'm with Sven Schüle, I know this is not a post about code review or code feedback but avoid the use of goto

[flok]

Possibly yes, but I have no idea where.
Note that the movegen is a bit slow, that doesn't help either.

Is there a simple way to compile Embla under Windows using MinGW or MinGW64? I tried but failed even after uncommenting some Linux-specific pieces of code ...

I don't know abut mingw, but I used to compile it using cygwin; no problem.

1) My old review comment that I made several times already You generate moves for both sides, only to be prepared for a later mobility calculation during static eval. But:
- Mobility does not involve king or pawn moves, so you go through both move lists again during mobility calculation and exclude these, counting all others. That is a lot of wasted effort.

Yes but the mobility is not calculated nor used.
That function calcMobility is never called.

[quote2) You use the same move generator for full-width search and for quiescence search. So in QS you go through the move list and remove all quiet moves which is a lot of effort. You'd better use a separate move generator for captures and promotions (after fixing mobility calculation as mentioned above).[/quote]

Agreed. Not trivial Working on it.

[Sven]

1) My old review comment that I made several times already You generate moves for both sides, only to be prepared for a later mobility calculation during static eval. But:
- Mobility does not involve king or pawn moves, so you go through both move lists again during mobility calculation and exclude these, counting all others. That is a lot of wasted effort.

Yes but the mobility is not calculated nor used.
That function calcMobility is never called.

Ok, missed that. But then why do you continue to generate two move lists? Without calcMobility() I see no part of your program that uses the opponent's move list.

2) You use the same move generator for full-width search and for quiescence search. So in QS you go through the move list and remove all quiet moves which is a lot of effort. You'd better use a separate move generator for captures and promotions (after fixing mobility calculation as mentioned above).

Agreed. Not trivial Working on it.

Why is that not trivial? Simply add a second set of methods to class ChessPiece that generate "tactical" moves only, and call these in a new move generation method of class Scene which you use in quiesceSearch(). You can do that in one hour.

[flok]

1) My old review comment that I made several times already You generate moves for both sides, only to be prepared for a later mobility calculation during static eval. But:
- Mobility does not involve king or pawn moves, so you go through both move lists again during mobility calculation and exclude these, counting all others. That is a lot of wasted effort.

Yes but the mobility is not calculated nor used.
That function calcMobility is never called.

Ok, missed that. But then why do you continue to generate two move lists? Without calcMobility() I see no part of your program that uses the opponent's move list.

E.g. in qs there is that BLIND code. It checks if a piece is protected or not. I determine that during movegen.

Depth 14 takes 3.8s without blind and with only 1 color generated and 3.3s with blind and both colors generated. If I replace it by something that checks on the spot, then ttd goes up to 10s.

2) You use the same move generator for full-width search and for quiescence search. So in QS you go through the move list and remove all quiet moves which is a lot of effort. You'd better use a separate move generator for captures and promotions (after fixing mobility calculation as mentioned above).

Agreed. Not trivial Working on it.

Why is that not trivial? Simply add a second set of methods to class ChessPiece that generate "tactical" moves only, and call these in a new move generation method of class Scene which you use in quiesceSearch(). You can do that in one hour.

I did that in an hour and then it suddenly did depth 31 in a few seconds So clearly this has side effects and haven't figured out what.

[flok]

E.g. in qs there is that BLIND code. It checks if a piece is protected or not. I determine that during movegen.

Depth 14 takes 3.8s without blind and with only 1 color generated and 3.3s with blind and both colors generated. If I replace it by something that checks on the spot, then ttd goes up to 10s.

Hmmm and it now plays invalid moves.

[pgn][Event "?"]
[Site "vardan"]
[Date "2017.10.22"]
[Round "3"]
[White "Embla"]
[Black "dorpsgek"]
[Result "0-1"]
[ECO "B97"]
[Opening "Sicilian"]
[PlyCount "62"]
[Termination "illegal move"]
[TimeControl "40/10+0.25"]
[Variation "Najdorf, 7...Qb6"]

1. e4 {book} c5 {book} 2. Nf3 {book} d6 {book} 3. d4 {book} cxd4 {book}
4. Nxd4 {book} Nf6 {book} 5. Nc3 {book} a6 {book} 6. Bg5 {book} e6 {book}
7. f4 {book} Qb6 {book} 8. Qd3 {book} Qxb2 {book} 9. Rb1 {book} Qa3 {book}
10. f5 {book} Nc6 {book} 11. fxe6 {book} fxe6 {book} 12. Nxc6 {book} bxc6 {book}
13. e5 {book} dxe5 {book} 14. Bxf6 {book} gxf6 {book} 15. Be2 {book} Be7 {book}
16. Bh5+ {book} Kf8 {book} 17. Qe3 {book} Rg8 {book} 18. Qh6+ {book} Rg7 {book}
19. Rb3 {book} Qa5 {book} 20. O-O {book} Qc5+ {book} 21. Kh1 {book} f5 {book}
22. Ne4 {book} Qc4 {+0.63/6 0.49s} 23. Nd2 {-3.80/4 0.22s} Qxf1+ {+1.51/7 0.39s}
24. Nxf1 {-2.65/7 0.24s} Bg5 {+1.44/9 0.58s} 25. Qxg7+ {-2.54/7 0.24s}
Kxg7 {+1.41/8 0.83s} 26. Be8 {-2.63/7 0.30s} c5 {+1.50/8 0.82s}
27. Bc6 {-2.63/5 0.42s} Ra7 {+1.58/8 0.60s} 28. Rb8 {-2.67/5 0.42s}
Bd7 {+2.34/8 0.65s} 29. Bxd7 {-2.60/7 0.28s} Rxd7 {+2.77/7 0.51s}
30. Rb6 {-2.57/6 0.43s} Rd1 {+4.81/8 0.87s} 31. Kg1 {-5.62/7 0.41s}
Be3+ {+1000.01/2 0.004s, White makes an illegal move: b6b7} 0-1[/pgn]


https://github.com/flok99/Embla/tree/onecolor

[Sven]

https://github.com/flok99/Embla/tree/onecolor

Either there are more changes in that branch than what you planned to do, or your Git repo is not up to date again. So currently I can't see what you actually changed.

Also I can't build it even with most recent Cygwin.

[Guenther]

E.g. in qs there is that BLIND code. It checks if a piece is protected or not. I determine that during movegen.

Depth 14 takes 3.8s without blind and with only 1 color generated and 3.3s with blind and both colors generated. If I replace it by something that checks on the spot, then ttd goes up to 10s.

Hmmm and it now plays invalid moves.

[pgn][Event "?"]
[Site "vardan"]
[Date "2017.10.22"]
[Round "3"]
[White "Embla"]
[Black "dorpsgek"]
[Result "0-1"]
[ECO "B97"]
[Opening "Sicilian"]
[PlyCount "62"]
[Termination "illegal move"]
[TimeControl "40/10+0.25"]
[Variation "Najdorf, 7...Qb6"]

1. e4 {book} c5 {book} 2. Nf3 {book} d6 {book} 3. d4 {book} cxd4 {book}
4. Nxd4 {book} Nf6 {book} 5. Nc3 {book} a6 {book} 6. Bg5 {book} e6 {book}
7. f4 {book} Qb6 {book} 8. Qd3 {book} Qxb2 {book} 9. Rb1 {book} Qa3 {book}
10. f5 {book} Nc6 {book} 11. fxe6 {book} fxe6 {book} 12. Nxc6 {book} bxc6 {book}
13. e5 {book} dxe5 {book} 14. Bxf6 {book} gxf6 {book} 15. Be2 {book} Be7 {book}
16. Bh5+ {book} Kf8 {book} 17. Qe3 {book} Rg8 {book} 18. Qh6+ {book} Rg7 {book}
19. Rb3 {book} Qa5 {book} 20. O-O {book} Qc5+ {book} 21. Kh1 {book} f5 {book}
22. Ne4 {book} Qc4 {+0.63/6 0.49s} 23. Nd2 {-3.80/4 0.22s} Qxf1+ {+1.51/7 0.39s}
24. Nxf1 {-2.65/7 0.24s} Bg5 {+1.44/9 0.58s} 25. Qxg7+ {-2.54/7 0.24s}
Kxg7 {+1.41/8 0.83s} 26. Be8 {-2.63/7 0.30s} c5 {+1.50/8 0.82s}
27. Bc6 {-2.63/5 0.42s} Ra7 {+1.58/8 0.60s} 28. Rb8 {-2.67/5 0.42s}
Bd7 {+2.34/8 0.65s} 29. Bxd7 {-2.60/7 0.28s} Rxd7 {+2.77/7 0.51s}
30. Rb6 {-2.57/6 0.43s} Rd1 {+4.81/8 0.87s} 31. Kg1 {-5.62/7 0.41s}
Be3+ {+1000.01/2 0.004s, White makes an illegal move: b6b7} 0-1[/pgn]


https://github.com/flok99/Embla/tree/onecolor

BTW testing relatively weak programs with such huge books/late positions surely is not recommended,
because you hide a lot more problems then you already have.

Moreover if those are really book moves it seems you have added a losing move too? 20...Qc5+?? wastes a decisive tempo and loses on the spot objectively.