Glaurung 1.0 beta 1

[Tord Romstad]

Hi all,

The source code for Glaurung 1.0 beta 1 can be downloaded by clicking this link. I will say more about the playing strength related improvements compared to Glaurung Mainz when the final 1.0 version is released; for now I will only describe the new features:

• New and improved (?) opening book. The opening book format has been changed, the book from Glaurung Mainz will not work. A new book file can be found here.
• MultiPV mode. Between 1 and 512 PVs can be displayed.
• More complete support for the UCI "go" command. Glaurung now understands the "searchmoves" "nodes", "depth" and "movetime" parameters. For the less technical people among you, this means that you can now instruct Glaurung to search just a few moves rather than all moves in a position, and that you can ask it to search to some fixed depth or for some fixed amount of time. Exactly how to do this depends on your GUI.
• Several new UCI options. Inspect the Readme.txt file for details.

Glaurung 1.0 beta 1 should not be used in serious tournaments. If you run a serious tournament, use the old Glaurung Mainz, or ask me for my latest development version (Glaurung 060105, which plays in the recently started CEGT league). Glaurung 1.0 beta 1 and 060105 should play exactly the same moves in all positions, the only difference is that a few new features (most notably MultiPV mode) has been added in 1.0 beta 1. Because 1.0 beta 1 is not very thoroughly tested yet and may contain unexpected bugs, I recommend using 060105 in serious tournaments.

I would appreciate if some of you could take the time to test the new features in 1.0 beta 1, especially MultiPV mode and the new opening book. Please report any bugs you find by e-mail (the address can be found at the end of the Readme.txt file) or directly on this forum.

When all serious problems appear to be fixed, I plan to release the final 1.0 version.

Tord

[Jim Ablett]

Hi Tord,

Intel Compiler 9 build here >

http://www11.rapidupload.com/d.php?file ... epath=1964

best wishes,

Jim.

[Peter Eizenhammer]

@Tord:
Hello, great news, guess it is christmas time again, well, at least for me it is

Later more.

@ Jim:
thx a lot, your build seems to work fine here on Win XP.


Peter

[Greg Simpson]

The Intel compile seems to be about 4% slower on my Athlon XP system when analyzing the start position.

[Tord Romstad]

Intel Compiler 9 build here

Thanks, Jim!

I added your binary as a download on my page, too:
http://www.glaurungchess.com/beta/g10b1.zip

Hello, great news, guess it is christmas time again, well, at least for me it is

Thanks for your enthusiasm, but please don't get too optimistic. Glaurung 1.0 beta 1 is almost certainly stronger than Glaurung Mainz, but not by a big amount. The last half year I have been busy with other tasks, and Glaurung hasn't changed much at all.

The Intel compile seems to be about 4% slower on my Athlon XP system when analyzing the start position.

4% slower than what? Jim's binary is the only one I have seen so far. If you mean that it is 4% slower than Glaurung Mainz, this is not unexpected. The recently added static null move pruning slows the program down a little.

Tord

[Jim Ablett]

Greg Simpson wrote:
The Intel compile seems to be about 4% slower on my Athlon XP system when analyzing the start position.

4% slower than what? Jim's binary is the only one I have seen so far. If you mean that it is 4% slower than Glaurung Mainz, this is not unexpected. The recently added static null move pruning slows the program down a little.

Tord

Another reason is Bryan Hoffman probably compiled that
version and his are always the fastest, but I consider to get within 4%
of Bryan's to be an achievement.

Jim.

[Bryan Hofmann]

Greg Simpson wrote:
The Intel compile seems to be about 4% slower on my Athlon XP system when analyzing the start position.

4% slower than what? Jim's binary is the only one I have seen so far. If you mean that it is 4% slower than Glaurung Mainz, this is not unexpected. The recently added static null move pruning slows the program down a little.

Tord

Another reason is Bryan Hoffman probably compiled that
version and his are always the fastest, but I consider to get within 4%
of Bryan's to be an achievement.

Jim.

What's this within 4% of my compiles, I'm back to the lab to eek out another 10 atleast.......

':D'

Bryan

[Jim Ablett]

What's this within 4% of my compiles, I'm back to the lab to eek out another 10 atleast.......

Don't you dare! ... quick! stop him someone!

Jim.

[Dann Corbit]

Here's another one.
http://cap.connx.com/chess-engines/new- ... ng.exe.bz2

[Jim Ablett]

Here's another one.
http://cap.connx.com/chess-engines/new- ... ng.exe.bz2

Hi Dann,

I'm getting a

PGORT80.DLL was not found error

with your build

regards,

Jim.

[Dann Corbit]

Oops, my mistake. Try the download again.

That was the version in my runtime directory that I used for profiling (and hence referenced the profiling dlls).
I have replaced it with the version that incorporates the profiling feedback.

The problem should be gone now.

[Tord Romstad]

Hello guys,

I like your competition in compiling the fastest possible Glaurung executable. Keep it up, but please save your best efforts until the final Glaurung 1.0 is ready.

Nobody has reported about how the new and experimental features (MultiPV, searchmoves, fixed depth, fixed time and fixed node count searches) in 1.0 beta 1 work yet, which makes me conclude that one of the following must be true:

1. Everything works perfectly
2. Nobody cares
3. Both of the above

In all three cases, I can probably assume that it is safe to release the final 1.0 version soon.

There is one known bug in 1.0 beta 1: The engine will always use its own book, even if the OwnBook UCI parameter is false. Thanks to Wilhelm Hudetz for helping me to find this bug. Version 1.0 will fix this bug, add the UCI_AnalyseMode UCI option, and possibly have slightly different default settings for the search and evaluation parameters. In particular, I want to find the optimal value of "Static pruning depth". The default value in 1.0 beta 1 is 1 (i.e. static null move pruning only in the last ply of the main search), but my current tests indicate that 2 plies is probably a bit better. I need to test this a bit more thoroughly.

Tord

[Patrick Buchmann]

Hi Tord,

Glaurung 1.0 beta 1 would have a rating for 2589 (2nd in the UEL today)

Glaurung Mainz have 2530 for 1.238 evaluated games.

Code: Select all

Tournoi d'entr?e HS-Book.abk
Le Fou numerique, 2006.01.10 - 2006.01.11
                           Score       1    2
-----------------------------------------------
 1: Glaurung 1.0 beta 1  61.0 / 84   16w+ 16b-
 2: AnMon 5.53            2.0 /  2    1b+  1w+
 3: Arion 1.6             2.0 /  2    1b+  1w+
 4: Dragon 4.6            1.5 /  2    1b=  1w+
 5: SlowChess Blitz WV    1.5 /  2    1b+  1w=
 6: Adam 3.0              1.0 /  2    1b=  1w=
 7: Frenzee 200           1.0 /  2    1b-  1w+
 8: Gaia 3.2              1.0 /  2    1b+  1w-
 9: Ktulu 4.2             1.0 /  2    1b-  1w+
10: Pepito v1.59          1.0 /  2    1b-  1w+
11: Pharaon 3.3           1.0 /  2    1b-  1w+
12: Amyan 1.597           1.0 /  2    1b=  1w=
13: Snitch 1.2.2          1.0 /  2    1b=  1w=
14: Spike 1.0a Mainz      1.0 /  2    1b=  1w=
15: Terra 3.4             1.0 /  2    1b+  1w-
16: Zappa 1.1             1.0 /  2    1b-  1w+
17: Queen 3.09            0.5 /  2    1b-  1w=
18: Glaurung Mainz        0.5 /  2    1b-  1w=
19: Aice 0.97             0.5 /  2    1b=  1w-
20: SOS 5.1               0.5 /  2    1b=  1w-
21: Nejmet 3.07           0.5 /  2    1b=  1w-
22: Aristarch 4.50        0.5 /  2    1b-  1w=
23: Tornado 0.84.2        0.5 /  2    1b-  1w=
24: Ufim 7.01             0.5 /  2    1b-  1w=
25: Yace Paderborn        0.5 /  2    1b=  1w-
26: Booot 4.75            0.5 /  2    1b=  1w-
27: Patzer 3.61           0.0 /  2    1b-  1w-
28: Abrok 5.0             0.0 /  2    1b-  1w-
29: Fruit 2.1             0.0 /  2    1b-  1w-
30: Chispa 4.0.3          0.0 /  2    1b-  1w-
31: Ruffian 1.0.5         0.0 /  2    1b-  1w-
32: Sjeng 12.13           0.0 /  2    1b-  1w-
33: Delphil 1.5b          0.0 /  2    1b-  1w-
34: Hermann 1.6           0.0 /  2    1b-  1w-
35: Homer 1.02            0.0 /  2    1b-  1w-
36: Diablo 0.4            0.0 /  2    1b-  1w-
37: Tao 5.6               0.0 /  2    1b-  1w-
38: List 5.12             0.0 /  2    1b-  1w-
39: Madeleine 0.2         0.0 /  2    1b-  1w-
40: Muse 0.899b           0.0 /  2    1b-  1w-
41: WJChess v1.64         0.0 /  2    1b-  1w-
42: Naum 1.8              0.0 /  2    1b-  1w-
43: Ayito 0.2.994         0.0 /  2    1b-  1w-
-----------------------------------------------
84 games: +35 =20 -29


PGN on my homepage

Regards,
Patrick

[Peter Eizenhammer]

Hello Tord,

there is a problem here on my machine with Glaurung and Arena 1.1.
When one tries to clear the hashtables
(right click on engine - commands - clear hashtables)
Glaurung exits with an exception.
Happens both to Jim's and Dann's build.
(I would guess that it is connected with the new option static evaluation cache,
but on the other hand it happens even when this option is disabled.)


The new MV mode works great, I would say, I compared it with Fritz9 and the latest Toga
and it seemed to be quite effective. A fine feature, certainly of high value for many chess players.

btw. could you say some more words about that static eval cache and how it is meant?
For example if I want a fair match between two engines, lets say 128Mb each, how would you split the 128 for Glaurung?
(or add the static eval cache to the 128, because one can say that it is an additional feature the other engine does not have?)
You may not yet have enough data to give a good recommendation,
but nevertheless ...

Peter

[Tord Romstad]

Hi Tord,

Glaurung 1.0 beta 1 would have a rating for 2589 (2nd in the UEL today)

Hi Patrick,

Thanks for these great results! They are probably a bit too good, as is usually the case when a new Glaurung version appears on the UEL list. It will be interesting to see how the final 1.0 version will end up.

Hello Tord,

there is a problem here on my machine with Glaurung and Arena 1.1.
When one tries to clear the hashtables
(right click on engine - commands - clear hashtables)
Glaurung exits with an exception.
Happens both to Jim's and Dann's build.
(I would guess that it is connected with the new option static evaluation cache,
but on the other hand it happens even when this option is disabled.)

Peter,

Thank you very much for your bug report. It is not connected to the static evaluation cache, and has nothing to do with the hash table. The problem is that Glaurung does not have the "Clear Hash" UCI option, and it crashes instantly when you send it a setoption command with a non-existant option. You can try running it from the command line and type "setoption name Foo value 0", and the program will crash. I didn't notice this until now, because most GUIs never sends any "setoption" commands with options not supported by the engine.

The bug was introduced when I recently replaced my old UCI option handling code. I replaced the ugly old code with some much better code from the evolving program which will eventually be released as Glaurung 2.0, and made a stupid mistake when adapting the new code to the old program. It's easy to fix, and will of course be fixed in 1.0.

The new MV mode works great, I would say, I compared it with Fritz9 and the latest Toga
and it seemed to be quite effective. A fine feature, certainly of high value for many chess players.

I'm happy to hear that it works. It seemed to work OK in my own tests, but without a supporting GUI it was hard to be 100% sure.

btw. could you say some more words about that static eval cache and how it is meant?
For example if I want a fair match between two engines, lets say 128Mb each, how would you split the 128 for Glaurung?
(or add the static eval cache to the 128, because one can say that it is an additional feature the other engine does not have?)
You may not yet have enough data to give a good recommendation,
but nevertheless ...

I don't have enough data, and moreover this seems to vary a lot between different machines. You will just have to experiment to find the best size of the static eval cache. This is quite easy to do. The eval cache has no effect on the search or evaluation; the program will always search exactly the same tree and return exactly the same score regardless of the cache size. The only thing that changes is the nodes/second count.

Another question is of course how much memory it is fair to give Glaurung for the eval cache in engine vs engine matches. I think a good solution would be to give it the same amount that other engines are given for the Nalimov EGTB cache. Glaurung does not support EGTBs, and probably never will.

Tord

[Peter Eizenhammer]

Thx for your explanations, Tord, always a pleasure.

will eventually be released as Glaurung 2.0, ...

It's easy to fix, and will of course be fixed in 1.0.

great

Another question is of course how much memory it is fair to give Glaurung for the eval cache in engine vs engine matches. I think a good solution would be to give it the same amount that other engines are given for the Nalimov EGTB cache. Glaurung does not support EGTBs, and probably never will.

ok, I hope I got it a litlle better now.
I'll try some sizes and simply give the best one.
Who says that eng-eng matches have to be fair?

Peter

[Tord Romstad]

btw. could you say some more words about that static eval cache and how it is meant?
For example if I want a fair match between two engines, lets say 128Mb each, how would you split the 128 for Glaurung?

On second thought, I think I can give some more specific advice about this. If the static eval cache improves performance at all on your machine, it is likely that a big cache will always give slightly better results than a small cache. However, this is always just a linear speedup. As explained before, the number of nodes needed to complete a search to a given depth will not change, the only thing that changes is that the nodes/second count increases by a few percent.

The main hash table, on the other hand, dramatically decreases the size of the search tree, especially at high search depths. When the computer thinks for several minutes or more, the difference in node count for a given depth between 64 MB and 128 MB hash could easily be a factor of 2. It follows that at slow time controls, it is always best to give the program a huge main hash table, and use whatever memory is left for the static eval cache. At fast time controls, the program probably doesn't fill the entire hash table anyway, and it makes sense to reduce the size of the hash table and increase the static eval cache.

With slightly more than 128 MB of total memory for the engine, I would recommend using 128 MB hash and 4 MB (or as much as you can afford) for the static eval cache at slow time controls, and 64 MB hash and 64 MB static eval cache for blitz games.

One last note: The static eval cache and the main hash table must both have a size which is a power of 2. If you give a number which is not a power of 2, it will be rounded down to the closest power of 2.

Tord

[Uri Blass]

I found a bug in glaurung multi-pv analysis in the first position that I tried
with it.

Here is the first position that I tried
I gave it 45 options in multi-pv mode.

Note that 1.Nc3 is mate in 3 but glaurung could not find it in the best 45 moves.

I also give fruit's analysis and note that I did not try to check if the analysis of fruit is correct.


New game
R6R/3Q4/1Q4Q1/4Q3/2Q4Q/Q4Q2/pp1Q4/kBNN1KB1 w - - 0 1

Analysis by Glaurung 1.0 beta 1:

1. +- (#1): 1.Qaxb2#
2. +- (#1): 1.Qdxb2#
3. +- (#1): 1.Qcxa2#
4. +- (#1): 1.Nb3#
5. +- (#1): 1.Qexb2#
6. +- (#1): 1.Qaxa2#
7. +- (#1): 1.Qbxb2#
8. +- (#2): 1.Qee3 bxc1Q 2.Qdxa2#
9. +- (#2): 1.Qee2 bxc1Q 2.Qaxa2#
10. +- (#2): 1.Qeh2 bxc1Q 2.Qaxa2#
11. +- (#2): 1.Qee6 bxc1Q 2.Qaxa2#
12. +- (#2): 1.Qeb5 bxc1Q 2.Qaxa2#
13. +- (#2): 1.Qea5 bxc1Q 2.Qaxa2#
14. +- (#2): 1.Qec5 bxc1Q 2.Qaxa2#
15. +- (#2): 1.Qee1 bxc1Q 2.Qaxa2#
16. +- (#2): 1.Qeh5 bxc1Q 2.Qaxa2#
17. +- (#2): 1.Nd3 Kxb1 2.Qaxb2#
18. +- (#2): 1.Qgg7 Kxb1 2.Qaxb2#
19. +- (#2): 1.Qgf6 Kxb1 2.Qaxb2#
20. +- (#2): 1.Qgf7 Kxb1 2.Qaxb2#
21. +- (#2): 1.Qgg8 Kxb1 2.Qaxb2#
22. +- (#2): 1.Qgg2 Kxb1 2.Qaxb2#
23. +- (#2): 1.Qge6 Kxb1 2.Qaxb2#
24. +- (#2): 1.Qgc6 Kxb1 2.Qaxb2#
25. +- (#2): 1.Qgh6 Kxb1 2.Qaxb2#
26. +- (#2): 1.Qgg3 Kxb1 2.Qaxb2#
27. +- (#2): 1.Qgg4 Kxb1 2.Qaxb2#
28. +- (#2): 1.Qgd6 Kxb1 2.Qaxb2#
29. +- (#2): 1.Qgg5 Kxb1 2.Qaxb2#
30. +- (#2): 1.Qgh5 Kxb1 2.Qaxb2#
31. +- (#2): 1.Qge8 Kxb1 2.Qaxb2#
32. +- (#2): 1.Qef5 bxc1R 2.Qab2#
33. +- (#2): 1.Qee7 bxc1R 2.Qab2#
34. +- (#2): 1.Qee8 bxc1R 2.Qab2#
35. +- (#2): 1.Qeb8 bxc1R 2.Qab2#
36. +- (#2): 1.Qec7 bxc1R 2.Qab2#
37. +- (#2): 1.Qeg3 bxc1R 2.Qab2#
38. +- (#2): 1.Qeg5 bxc1R 2.Qab2#
39. +- (#2): 1.Qed5 bxc1R 2.Qab2#
40. = (0.00): 1.Qaf8
41. = (0.00): 1.Qda7
42. = (0.00): 1.Rae8
43. = (0.00): 1.Q7d6
44. = (0.00): 1.Q7d3
45. = (0.00): 1.Qhh3

(, 12.01.2006)


New game
R6R/3Q4/1Q4Q1/4Q3/2Q4Q/Q4Q2/pp1Q4/kBNN1KB1 w - - 0 1

Analysis by Fruit 2.2:

1. +- (#1): 1.Qdxb2#
2. +- (#1): 1.Qaxa2#
3. +- (#1): 1.Qaxb2#
4. +- (#1): 1.Qcxa2#
5. +- (#1): 1.Qexb2#
6. +- (#1): 1.Qbxb2#
7. +- (#1): 1.Nb3#
8. +- (#2): 1.Nd3 Kxb1 2.Qdxb2#
9. +- (#2): 1.Qgg7 Kxb1 2.Qdxb2#
10. +- (#2): 1.Qgg2 Kxb1 2.Qdxb2#
11. +- (#2): 1.Qgg5 Kxb1 2.Qdxb2#
12. +- (#2): 1.Qgf7 Kxb1 2.Qdxb2#
13. +- (#2): 1.Qgg3 Kxb1 2.Qdxb2#
14. +- (#2): 1.Qgg4 Kxb1 2.Qdxb2#
15. +- (#2): 1.Qgh6 Kxb1 2.Qdxb2#
16. +- (#2): 1.Qgf6 Kxb1 2.Qdxb2#
17. +- (#2): 1.Qgh5 Kxb1 2.Qdxb2#
18. +- (#2): 1.Qgg8 Kxb1 2.Qdxb2#
19. +- (#2): 1.Qgc6 Kxb1 2.Qdxb2#
20. +- (#2): 1.Qge6 Kxb1 2.Qdxb2#
21. +- (#2): 1.Qgd6 Kxb1 2.Qdxb2#
22. +- (#2): 1.Qge8 Kxb1 2.Qdxb2#
23. +- (#2): 1.Qee7 bxc1Q 2.Qdxa2#
24. +- (#2): 1.Qeg5 bxc1Q 2.Qdxa2#
25. +- (#2): 1.Qeg3 bxc1Q 2.Qdxa2#
26. +- (#2): 1.Qeb5 bxc1Q 2.Qdxa2#
27. +- (#2): 1.Qec7 bxc1Q 2.Qdxa2#
28. +- (#2): 1.Qed5 bxc1Q 2.Qdxa2#
29. +- (#2): 1.Qee6 bxc1Q 2.Qdxa2#
30. +- (#2): 1.Qeh2 bxc1Q 2.Qdxa2#
31. +- (#2): 1.Qef4 bxc1Q 2.Qdxa2#
32. +- (#2): 1.Qea5 bxc1Q 2.Qdxa2#
33. +- (#2): 1.Qeh5 bxc1Q 2.Qdxa2#
34. +- (#2): 1.Qed6 bxc1Q 2.Qdxa2#
35. +- (#2): 1.Qee1 bxc1Q 2.Qdxa2#
36. +- (#2): 1.Qee2 bxc1Q 2.Qdxa2#
37. +- (#2): 1.Qef5 bxc1Q 2.Qdxa2#
38. +- (#2): 1.Qec5 bxc1Q 2.Qdxa2#
39. +- (#2): 1.Qeb8 bxc1Q 2.Qdxa2#
40. +- (#2): 1.Qee8 bxc1Q 2.Qdxa2#
41. +- (#2): 1.Qee4 bxc1Q 2.Qdxa2#
42. +- (#2): 1.Qee3 bxc1Q 2.Qdxa2#
43. +- (#3): 1.Nc3 bxc1Q+ 2.Nd1+ Qb2 3.Qdxb2#
44. = (0.00): 1.Bxa2
45. = (0.00): 1.Nxb2

(, 12.01.2006)

[Uri Blass]

Here is a diagram of the relevant position

[diag]R6R/3Q4/1Q4Q1/4Q3/2Q4Q/Q4Q2/pp1Q4/kBNN1KB1 w - - 0 1[/diag]

[Tord Romstad]

Hi Uri,

Thanks for the bug report! Unfortunately it's too late to fix this in version 1.0. Perhaps I will prepare a 1.01 version soon which fixes this problem.

I think this bug will only appear in positions with a forced mate, but I could be wrong.

Tord