Winboard Forum

Hi,

I have a new version of my engine, Goyaz (http://wferreirajr.googlepages.com/index-en.htm), and I got about 100% of speed-up in the nps (nodes per second) compared to version 2.

It became better and some people (including myself) noticed it in the games.

However, I got an e-mail saying that the nps is the same of version 2 and it lost performance (maybe because of the increasing in the code size).

Could it be possible that this difference be explained by the computers being differents?

The changes that increased the nps were in my eval function: it doesn't scan all the board again, but only change the value of the position based on the "from" and "to" squares (it's only a piece-square table evaluator).

I don't see how this could increase the speed in some systems and do nothing in others.

Could someone help me?

Thanks!

Hi Wander

I hope somebody will be able to answer your question. Did you get my bug report about illegal moves ?

Olivier

Wander Ferreira Jr wrote:Hi,

I have a new version of my engine, Goyaz (http://wferreirajr.googlepages.com/index-en.htm), and I got about 100% of speed-up in the nps (nodes per second) compared to version 2.

It became better and some people (including myself) noticed it in the games.

However, I got an e-mail saying that the nps is the same of version 2 and it lost performance (maybe because of the increasing in the code size).

Could it be possible that this difference be explained by the computers being differents?

Yes, I think so. My engine Buzz also runs incredibly slowly on some platforms (32-bit computers) but runs relatively fast on others (64-bit computers). There might be some processor specific features that you might be using which run at different relative speeds in your CPU and other CPUs.

The changes that increased the nps were in my eval function: it doesn't scan all the board again, but only change the value of the position based on the "from" and "to" squares (it's only a piece-square table evaluator).

I don't see how this could increase the speed in some systems and do nothing in others.

I think so too. You might want to check the validity of the report you got first. There might have been a silly mistake somewhere.

Could someone help me?

Thanks!

hi,
i also agree with Pradu. My personal experience is my programme being stronger on an amd athlon-XP (compared to other engines),
but weaker on an pIII (compared to the same engines).
Maybe due to the compiler/processor couple doing
some optimizations in a case and other optimizations in other cases?
yves

Thanks.
To take advantage of these differences in the computers, someone would need to make a different .exe for best performance in each one of those?

It seems to me that you should not worry too much about speed yet. Engines around this level are often weak not because of lack of speed, or because of their simple design, (lack of implemented features), but because of bugs.

A good reference would be micro-Max 1.6, which is not much more than a flat alpha-beta search (no extensions or reductions of any kind) with an evaluation of untuned material (just the classical 1, 3, 3, 5, 9) and a primitive drive towards centralization for P,N,B,K.

No King safety, virtually no Pawn structure (it doesn't know about doubled Pawns or passers), no open Rook files... No opening book, no hash table, no EGTBs, no end-game knowledge whatsoever...

So it really has nothing. But it is too small to contain any bugs!

I tried micro-Max 1.6 against Goyaz 3 at 40/1' and 40/2', and it consistenly beat it (both with white and black). Despite the fact that Goyaz claims to outsearch it by 1 or 2 ply! This suggests you still have some bugs.

In the game where Goyaz lasted longest (which I thought would surely go draw, knowing how inept the early micro-Max versions are with passers) this is very clear:

Code: Select all

[Event "Computer chess game"]
[Site "Pentium IV"]
[Date "2007.08.31"]
[Round "-"]
[White "umax1_6w"]
[Black "GOYAZ"]
[Result "1-0"]
[TimeControl "40/120"]

1. Nc3 e6 2. e4 Qf6 3. Nf3 Nc6 4. Bc4 Qg6 5. O-O Qh5 6. d4 Bd6 7. e5 Bb4 8.
Nb5 Ba5 9. Bd2 a6 10. Nc3 Nge7 11. Ne2 Bxd2 12. Qxd2 Qf5 13. Bd3 Qh5 14.
Ng3 Qh6 15. Qxh6 gxh6 16. Nh5 d6 17. Nf6+ Kd8 18. Bxh7 Nd5 19. Nxd5 exd5
20. Bd3 Be6 21. h4 Kc8 22. a4 dxe5 23. dxe5 a5 24. Kh2 Nb4 25. Nd4 c5 26.
Nxe6 fxe6 27. Rac1 Rg8 28. Bb5 Rg4 29. Kh3 Re4 30. f4 Na2 31. Ra1 Nb4 32.
Rf2 d4 33. Kg3 Nd5 34. Bc4 Ra7 35. Bxd5 exd5 36. Kg4 Re3 37. Kf5 Kd7 38.
Rc1 Ra8 39. Kg6 Ra6+ 40. Kf5 Kc8 41. c4 dxc4 42. Rxc4 Rc6 43. Rfc2 d3 44.
Rc1 b6 45. R4c3 Rc7 46. Kg6 d2 47. Rd1 Re4 48. Kxh6 Rd7 49. Rc2 Re2 50. g4
Re4 51. Kg5 Re2 52. b3 Rg7+ 53. Kf5 Rd7 54. Kg5 Rg7+ 55. Kf5 Rxg4 ???? 56. Kxg4
Rg2+ 57. Kf3 Rh2 58. Kg4 Rg2+ 59. Kf3 c4 ???? 60. Kxg2 Kd7 61. Rxc4 Ke6 62. Rxd2
Kf5 63. Kf3 Kg6 64. Rd7 Kh5 65. Rc6 Kxh4 66. Rh6#
{White mates} 1-0


Obviously there is something wrong with your rep-draw code here: uMax 1.6, not recognizing rep-draws, falls in a repeat cycle despite its overwhelming Pawn front, but as soon as Goyaz can bring about the repeat it gives away a Rook instead (twice!).

Another dramatic loss for Goyaz (considering the simplicity of the opponent):

Code: Select all

[Event "Computer chess game"]
[Site "Pentium IV"]
[Date "2007.08.31"]
[Round "-"]
[White "umax1_6w"]
[Black "GOYAZ"]
[Result "1-0"]
[TimeControl "40/60"]

1. Nc3 e6 2. e4 Qf6 3. Nf3 Nc6 4. Bc4 Qg6 5. O-O Qh5 6. d4 Bd6 7. e5 Na5 8.
exd6 Nxc4 9. dxc7 Qa5 10. Qe1 Qxc7 11. Nd5 Qd6 12. Nc3 Nb6 13. Ne4 Qd5 14.
Bf4 Nc4 15. b3 Qf5 16. Bd6 Qd5 ???? 17. bxc4 Qxc4 18. Be5 Kf8 19. Nd6 Qxc2 ????
20. Rc1 Qd3 21. Rxc8+ Rxc8 22. Nxc8 Ne7 23. Qb4 Kg8 24. Nxe7+ Kf8 25. Ng6+ Kg8
26. Qf8#
{White mates} 1-0


It seems to me there are some blunders here that it should have surely recognized as such in the reported 5 or 6 ply. E.g. Qxc2, and 3 ply later you are a piece down. And I don't see any moves for black to push it over the horizon.

H.G.Muller wrote:Obviously there is something wrong with your rep-draw code here: uMax 1.6, not recognizing rep-draws, falls in a repeat cycle despite its overwhelming Pawn front, but as soon as Goyaz can bring about the repeat it gives away a Rook instead (twice!).

Yes, I know what is wrong. I am just trying to find a way to solve it:
If it finds a position that already happened, it evaluates it as zero and stops the search on that node.

If the game is already in a position that is a repeat (as in that game), all nodes are zero and it takes the first one (and here my ordering routine finishes me: captures are allways put in first, so if there is a repetition, Goyaz tends to capture even protected pieces).

I am rewriting my repetition recognization routine, but, for now, it is used only in some cases, to make the damage not so big.

About the other bugs, I am creating some type of debug file and will see what is happening. I think that the horizon effect is the cause of many of those moves, since I have absolutely no quiescense search, no extensions and no reductions.

With the quiescense search I have made (and with my null-moves), I can't take back the moves very well and, in no time, my engine's board is full of doubled kings, a lot of knigths, white and black pieces sharing the same square and so on... (this is the reason why I don't use neither of them)

I will have to make it work if I wan't more playing strength...

Thanks for the tips. I will concentrate more in this bugs.

Wander Ferreira Jr wrote:Yes, I know what is wrong. I am just trying to find a way to solve it:
If it finds a position that already happened, it evaluates it as zero and stops the search on that node.

Well, that seems OK. But you just shouldn't do it in the root. If the root is a repetition, claim draw. If one of the moves from the root leads to a repetition, it can't do any harm to score it as 0. But captures can never be repetitions, and bad captures should score worse than 0. So it should avoid those, and if all non-captures lead to repeats, it would indeed not matter which one it picks.

I think that the horizon effect is the cause of many of those moves, since I have absolutely no quiescense search, no extensions and no reductions.

Don't bother about looking for other bugs, then. Without a QS you cannot expect sensible play, as at any search depth the aim of the engine will become to capture a high piece just before the horizon. The search just doesn't converge at all (although I have heard claims that not having QS can be compensated by 4 plies of full-width search).

So concentrate on getting the QS running. If the error is as bad as you say, you shouldn't have much trouble tracking it down. (I know the effect! ) In uMax 1.6 I don't have a true QS, but a SEE-like search that only considers recaptures (actually captures of the piece that just moved, even if that was not a capture itself). That is not very accurate, but it is enough to make the search converge, as the side not having the move in the last ply only has to avoid positions in which it relies on a counter threat or a pin (i.e. opponent cannot capture an unsufficiently defended piece because you will retaliate on another square), which are not very common and usually not sound defences anyway.

You could simplify your engine a lot by not using different code for QS and normal search, but simply limit the move generation to captures if the requested depth <= 0. (And start with the stand-pat score equal to the current evaluation, rather than Alpha or -INF).

This is not correct that the search does not converge with no qsearch.

1)It certainly should converge to the theorethical result of the game (if the depth is infinite and if you have no bugs it should return the theoretical result of the game).

2)It is also not always correct that a program with no qsearch
will try to capture a high piece just before the horizon.

It is dependent on the evaluation function and the evaluation function certainly can consider the fact that a piece can be captured in the next ply or alternatively do not count material at all.

Uri

All true, but not of practical relevance here. We are dozens of orders of magnitude away from searching all the way to checkmate. And if Goyaz is meant to have a QS, whcich simply doesn't work yet, he won't have suche a static 'convergence accelerating term' in the evaluation.

I agree that a simple term accounting for hanging pieces as a replacement for QS would be enough to make the search converge within reachable search depths. I know that taking the best SEE is already quite good (though still some 80 Elo weaker than an all-captures QS). Probably the BLIND score (= counting the PieceValue difference of captures on defended pieces, or the victim value of any attacked and undefended piece) would already be good enough to obtain such convergence, despite the fact that it would overlook insufficiently defended (but not undefended) pieces.

H.G.Muller wrote:Don't bother about looking for other bugs, then. Without a QS you cannot expect sensible play, as at any search depth the aim of the engine will become to capture a high piece just before the horizon. The search just doesn't converge at all (although I have heard claims that not having QS can be compensated by 4 plies of full-width search).

So concentrate on getting the QS running. If the error is as bad as you say, you shouldn't have much trouble tracking it down. (I know the effect! )

Hi, I followed the advice and now I have a functional QS (I hope ).

The bugs I have in the implementation of it appears to be in the previous versions of Goyaz too. I was thinking that they were due to skip a move (the bug was shown in my null-moves and so in my Quiescense Search, were I had to put null-moves to simulate the "move different from capturing").

However, I saw Rebel's implementation of QS: a piece only captures another piece of same value or higher value. So, I changed my move generation routine and cut off the null-moves of my QS! But the bug was still in there. In fact, it is in Goyaz since it's birth. But I never noticed.

I waste all my weekend trying to find this bug (when I take back moves, other pieces appears), and have not been successfull.

So, I get tired of all this and now I save a copy of each board, so I can get back without calculations (not very efective, but the bug was gone ).

I am testing this new version, but it seems to be a little better than the version without QS.

Thanks!

Wander Ferreira Jr wrote:

H.G.Muller wrote:Obviously there is something wrong with your rep-draw code here: uMax 1.6, not recognizing rep-draws, falls in a repeat cycle despite its overwhelming Pawn front, but as soon as Goyaz can bring about the repeat it gives away a Rook instead (twice!).

Yes, I know what is wrong. I am just trying to find a way to solve it:
If it finds a position that already happened, it evaluates it as zero and stops the search on that node.

If the game is already in a position that is a repeat (as in that game), all nodes are zero and it takes the first one (and here my ordering routine finishes me: captures are allways put in first, so if there is a repetition, Goyaz tends to capture even protected pieces).

That's broken. How can you possibly have a repetition after playing a capture?

I am rewriting my repetition recognization routine, but, for now, it is used only in some cases, to make the damage not so big.

About the other bugs, I am creating some type of debug file and will see what is happening. I think that the horizon effect is the cause of many of those moves, since I have absolutely no quiescense search, no extensions and no reductions.

With the quiescense search I have made (and with my null-moves), I can't take back the moves very well and, in no time, my engine's board is full of doubled kings, a lot of knigths, white and black pieces sharing the same square and so on... (this is the reason why I don't use neither of them)

I will have to make it work if I wan't more playing strength...

Thanks for the tips. I will concentrate more in this bugs.

bob wrote:

Wander Ferreira Jr wrote:

H.G.Muller wrote:Obviously there is something wrong with your rep-draw code here: uMax 1.6, not recognizing rep-draws, falls in a repeat cycle despite its overwhelming Pawn front, but as soon as Goyaz can bring about the repeat it gives away a Rook instead (twice!).

Yes, I know what is wrong. I am just trying to find a way to solve it:
If it finds a position that already happened, it evaluates it as zero and stops the search on that node.

If the game is already in a position that is a repeat (as in that game), all nodes are zero and it takes the first one (and here my ordering routine finishes me: captures are allways put in first, so if there is a repetition, Goyaz tends to capture even protected pieces).

That's broken. How can you possibly have a repetition after playing a capture?

I understood that he explained that he has a bug and his program simply assumes that every move is a draw after repetition so it simply evaluate every move as 0.00 and plays the first move.

Capture certainly can happen after repetition.

Note that returning draw score from repetition position is logical except cases when the root position is repetition position.

I simply check in my search after every move that I make if it is a repetition and if it is a repetition I return draw score.

If the root position is repetition of previous position I do not care
because the root position does not happen after a move in my search.

You can say that it is also broken because repetition is not a draw by the rules but it is a simple solution that many programs use considering many commercial programs.

Of course for claiming a draw and stopping to play I check if the position repeats twice and one repetition is not enough.

Uri

Uri Blass wrote:I understood that he explained that he has a bug and his program simply assumes that every move is a draw after repetition so it simply evaluate every move as 0.00 and plays the first move.

Capture certainly can happen after repetition.

This is exactly the case!!!

I will work on this when I have some time. For now, I am just a little busy...