Winboard Forum

Hi Jim,

Something seems wrong with newer versions after rev. 222.
Typhoon rev 229 uses much more hash now than it should and did
before despite the same settings. Also it uses nearly the double amount of virtual ram
beneath physical ram.
With the settings as before which worked fine in my previous tournament
it used now around 200MB physical and 400MB! virtual ram.
(on my XP SP2 machine on my second WIN2KSP5 machine it goes up even to
> 500MB virtual ram!)

Also if I start it via double clicking only and type 'dump sizes'
I see a huge amount already for 'sizeof(SEARCHER_THREAD_CONTEXT)'
which is way beyond the normal number given in Scotts readme.

Also it produces a stackdump error message sometimes(would still play though),
probably because of using much too much ram?

Best regards,
Guenther

Code: Select all

sizeof(SEARCHER_THREAD_CONTEXT). . . . . 62130104 bytes

Code: Select all

Exception: STATUS_ACCESS_VIOLATION at eip=610B1765
eax=00000001 ebx=0022C510 ecx=28B4CE64 edx=60030000 esi=00000009 edi=00432A10
ebp=0022C698 esp=0022C500 program=c:\WinBoard\Typhoon_100r229\Typhoon_100r229.exe, pid 1580, thread main
cs=001B ds=0023 es=0023 fs=003B gs=0000 ss=0023
Stack trace:
Frame     Function  Args
0022C698  610B1765  (0F565CB0, 00000009, 00000000, FFFFFFFF)
0022CC88  610916B8  (00000007, 0F4A01B0, 0F4A0090, 00000201)
0022CD98  61006168  (00000000, 0022CDD0, 610054E0, 0022CDD0)
610054E0  61004416  (0000009C, A02404C7, E8610FE1, FFFFFF48)
 422202 [main] Typhoon_100r229 1580 _cygtls::handle_exceptions: Exception: STATUS_ACCESS_VIOLATION
 475191 [main] Typhoon_100r229 1580 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack)
</pre>

Oops what happened here? Typhoon seems not to recognize
the '--pawnhash' command anymore?

Code: Select all

recognized 'normal' (-1) as variant normal
WinBoard 4.2.7 + Typhoon_100r229
Reset(1, 0) from gameMode 0
recognized 'normal' (-1) as variant normal
GameEnds(0, (null), 2)
StartChildProcess (dir="c:\WinBoard\Typhoon_100r229") Typhoon_100r229 --hash 16384 --pawnhash 1024 --egtbpath C:\Sicherheit\Chess\Tbs
1132 >first : xboard
protover 2
1342 <first : Error (unknown argument): "--pawnhash"
1342 <first : Error (unknown argument): "1024"
4867 <first : Found 5-men endgame table bases.

Hi Guenther,

I had a look at 'main.c' in revision 222 and revision 228, this is where the command line parameter
functions are written. It seems --pawnhash is now an obsolete command. The function is not there anymore
in the source code.
Valid commands (still there in src) are: --hash --egtbpath --command --batch.

Memory usage is 123mb on my computer using

Code: Select all

--hash 16384


Which doesn't make a lot of sense. Without this command memory usage rockets up to about 350mb. There is also a small problem with Typhoon exiting (as you've noticed) with an non-fatal error and a stackdump that needs fixing.

Regards,
Jim.

Revision 230 just built.

I've adjusted the internal pawnhash allocation (can't be user-adjusted anymore) as defined in 'chess.h'

Code: Select all

#define PAWN_HASH_TABLE_SIZE (43690) // was 5.5Mb (per thread)  131072


Now using about 44mb.

Will be available on my homepage in about 30 mins.

Jim.

Jim Ablett wrote:Revision 230 just built.

I've adjusted the internal pawnhash allocation (can't be user-adjusted anymore) as defined in 'chess.h'

Code: Select all

#define PAWN_HASH_TABLE_SIZE (43690) // was 5.5Mb (per thread)  131072


Now using about 44mb.

Will be available on my homepage in about 30 mins.

Jim.

Will the stackdump error be solved with that too?
I noticed that all versions you built so far produce
that error after exiting from Winboard.
(and Danns early built still has the timing bug)
Moreover in a test game now rev 229 even crashed
in a winning position
Is it possible that there is a problem with the new
compiler and cygwin files?

Best regards,
Guenther

Debug snippet:

Code: Select all

1882276 <first : ---------------------------------------------
1882276 <first : Searched for  37.8 seconds, saw 32473169 nodes (19176305 qnodes) (858965 nps).
1882276 <first : tellothers d13, +6.37,  37.8s, 858965 nps, PV=
1882276 <first : Hashing percentages: (48.456 total, 46.536 useful)
1882276 <first : Pawn hash hitrate: 99.874 percent.
1882276 <first : Null move cutoff rate: 23.370 percent.
1882276 <first : Never used the avoid null move heuristic.
1882276 <first : Never used the quick null move heuristic.
1882276 <first : First move beta cutoff rate was 99.220 percent.
1882276 <first : Eval percentages: ( 9.32 hash, 88.02 lazy,  2.66 full)
1882276 <first : Extensions: (339192 check, 291 qcheck, 899 1mv, 0 !kmvs, 0 multi,
1882276 <first :              687083 pawn, 0 threat, 0 zug, 1360 sing, 10835 endg, 94187 recap)
1882276 <first : Avg. cpu cycles in eval:    110.3.
1885721 <second: 1 -214 0 3 Ke7
1885741 <second: 2 -225 0 53 Ke7 h5
1885741 <second: 3 -210 0 128 Ke7 Bc6 b4
1885761 <second: 4 -224 0 490 Ke7 Be4 b4 h5
1885761 <second: 5 -284 0 1223 Ke7 Kg6 b4 Be4 a4
1885781 <second: 5 -239 0 3049 h5 a4 bxa4 Kxf6 a3
1885821 <second: 6 -268 0 7874 Ke7 Kg6 a4 Be4 a3 Kxh6
1885821 <second: 7 -274 0 9164 Ke7 Bc6 b4 Kg6 Kd6 Ba4 Ke5
1885862 <second: 8 -277 0 12548 Ke7 Bc6 b4 Kg6 Kd6 Ba4 Ke6 Kxh6
1885882 <second: 9 -274 0 45790 Ke7 Bc6 b4 Kg6 Ke6 Kxh6 Kd6 Ba4 Ke5
1885902 <second: 10 -280 0 51757 Ke7 Bc6 b4 Kg6 Kd6 Ba4 h5 Kxh5 Kd5 Bc2
1885942 <second: 11 -283 0 77961 Ke7 Bc6 b4 Kg6 Kd6 Ba4 Ke6 Kxh6 f5 h5 Ke5
1885982 <second: 12 -285 0 264978 Ke7 Bc6 b4 Kg6 h5 Ba4 Ke6 Kxh5 Ke5 Bd7 f5 Bc6
1886022 <second: 12 -281 0 369984 Kg7 g3 b4 Bb3 h5 Bd1 Kf7 Bxh5+ Ke7 Bf3 a4 h5 a3
1886042 <second: 13 -292 0 571142 Kg7 g3 h5 Bf3 b4 Bxh5 a4 Be2 Kf7 Bc4+ Kg7 h5 a3 Bd5
1890749 <second: 13 -286 0 828292 Ke7 Bc6 b4 Kg6 Kd6 Ba4 Ke5 h5 f5 Kxh6 f4 Bc2 Kd4
1904548 <second: 14 -301 0 4135838 Ke7 a3 Kd6 Be4 Ke7 Kg6 h5 Kxh5 Kd6 Kg4 a4 Kf4 Ke6 h5
1909626 <second: 14 -301 0 5000000 Ke7 a3 Kd6 Be4 Ke7 Kg6 h5 Kxh5 Kd6 Kg4 a4 Kf4 Ke6 h5
1909626 <second: move f8e7
1909626 >first : time 83646
1909626 >first : otim 85636
1909626 >first : f8e7
1909766 <first : SetMoveTimer: 38 moves left to do this in 13:56.000 sec.
1909766 <first : SetMoveTimer: Soft time limit 00:22.000 seconds.
1909766 <first : SetMoveTimer: Hard time limit 01:28.000 seconds.
1909766 <first : SetMoveTimer: Checking input and timer every 32767 nodes.
1910307 <first : 10    683    53 415786       h5 b4 Kg6 f5 Kxh6 Kf6 Kh7 a4 h6 f4
1911348 <first : 11    690   158 1254090      h5 b4 Kg6 f5 Kxh6 Kf6 Bc6 f4 Kh7 Ke6 h6
1914242 <first : 12    747   446 3603969      h5 b4 Kg6 a4 Kxh6 Kf8 g4 b3 axb3 axb3 Bxb3 Ke7
1917066 <first :       3 [main] Typhoon_100r229 356 _cygtls::handle_exceptions: Exception: STATUS_ACCESS_VIOLATION
1917066 <first :    1008 [main] Typhoon_100r229 356 open_stackdumpfile: Dumping stack trace to Typhoon_100r229.exe.stackdump
Fatal Error: Error: first chess program (Typhoon_100r229 --hash 16384 --egtbpath C:\Sicherheit\Chess\Tbs ) exited unexpectedly
GameEnds(0, (null), 2)

Will the stackdump error be solved with that too?

No, still there I'm afraid. I'll do some experiments with older version's of cygwin and maybe try porting it to mingw-gcc.

Regards and thanks for error report.
Jim.

Jim Ablett wrote:

Will the stackdump error be solved with that too?

No, still there I'm afraid. I'll do some experiments with older version's of cygwin and maybe try porting it to mingw-gcc.

Regards and thanks for error report.
Jim.

My thanks to you!
You are a relentless fighter against foreign code

Best regards,
Guenther

Hi Jim

In a tourney Typhoon (build 230) refused to play move 81 as White (it was a 40/5 match against Anmon560 ). I played a second tourney against another engine (/mg 6) but it was the same.

Hope you can solve the problem. (The hash problem according to build 229 doesn't exist any more (or just not for me).)

Best regards

Hartmut

Jim Ablett wrote:Revision 230 just built.

I've adjusted the internal pawnhash allocation (can't be user-adjusted anymore) as defined in 'chess.h'

Code: Select all

#define PAWN_HASH_TABLE_SIZE (43690) // was 5.5Mb (per thread)  131072


Now using about 44mb.

Will be available on my homepage in about 30 mins.

Jim.

I started the Open Class now with version 230. It still had
the stackdump error after WB closed, but at least it played
and did not crash, did not use too much hash and finally won.
I will stay with it for now as long as no serious mishap arrives.

Best regards,
Guenther

I started the Open Class now with version 230. It still had
the stackdump error after WB closed, but at least it played
and did not crash, did not use too much hash and finally won.
I will stay with it for now as long as no serious mishap arrives.

Good news Guenther!. From my tests I would put Typhoon's strength on a par with Phalanx at the moment.

Revision 231 is out (in about 10 mins). Still with stackdump error (it's becoming my old friend):)
I've have noticed a small gradual increase in strength with each revision, so keep downloading and testing!

Hi Hartmut,

In a tourney Typhoon (build 230) refused to play move 81 as White (it was a 40/5 match against Anmon560 ).
I played a second tourney against another engine (/mg 6) but it was the same.

I tested Revision 231 to try and reproduce your error, but I couldn't, so maybe it's fixed now - time will tell.

best,
Jim.

Jim Ablett wrote:

I started the Open Class now with version 230. It still had
the stackdump error after WB closed, but at least it played
and did not crash, did not use too much hash and finally won.
I will stay with it for now as long as no serious mishap arrives.

Good news Guenther!. From my tests I would put Typhoon's strength on a par with Phalanx at the moment.

Revision 231 is out (in about 10 mins). Still with stackdump error (it's becoming my old friend):)
I've have noticed a small gradual increase in strength with each revision, so keep downloading and testing!

best,
Jim.

Hi Jim,

Sadly I was wrong and it seems I was just lucky to have produced
a game without a crash with version 230 at least on my P4 with
the tc 40/15.
I have now 3/4 games at 40/15, which all ended up in a crash
in an endgame and an access error(builds 229-231).
Even worser is that one of those is the game of Typhoon round 2 of the Open Class
I have to revert to Danns very first compile(what revision was this BTW?),
which still could lose on time sometimes, otherwise
I may need to take it out at all(which still can happen of course
if it crashes or lose on time 2 more times in the next 19 rounds)

I will send the logs/debugs to Scott or post them in the other thread about Typhoon bugs.

For now just the latest crash:

[Event "RWBC_Open_Class_7th_Edition"]
[Site "ESPRESSO"]
[Date "2006.07.21"]
[Round "2"]
[Number "36"]
[White "SSEChess_2050DC"]
[Black "Typhoon_100r231"]
[Result "*"]
[TimeControl "40/900"]
[Annotator "9. +0.07 8... -0.37"]

1. c4 Nf6 2. Nc3 g6 3. d4 d5 4. Nf3 Bg7 5. cxd5 Nxd5 6. e4 Nxc3 7. bxc3 c5
8. Be3 Nc6 {-0.37/10} 9. Bc4 {+0.07/10} cxd4 {-0.36/10} 10. cxd4 {+0.08/10}
Qa5+ {-0.22/10} 11. Bd2 {+0.42/9} Qc7 {-0.40/10} 12. Rc1 {+0.42/10}
O-O {-0.28/10} 13. d5 {+0.43/10} Ne5 {-0.11/10} 14. Be2 {+0.56/10}
Nxf3+ {-0.24/11} 15. Bxf3 {+0.47/9} Qd6 16. Qb3 {+0.54/10} Be5 {-0.25/10}
17. h3 {+0.46/10} f5 {+0.05/9} 18. Be3 {+0.99/9} fxe4 {+0.25/9} 19.
Bxe4 {+0.87/9} Kg7 {+0.15/9} 20. O-O {+1.33/9} a6 {-0.04/9} 21.
Kh1 {+1.34/9} Rb8 {-0.38/10} 22. Bb6 {+1.44/9} Ra8 {-0.50/10} 23.
Bc7 {+1.46/10} Qf6 {-0.83/9} 24. Bxe5 {+1.43/10} Qxe5 {-0.55/9} 25.
Rce1 {+1.44/9} Qd6 {-0.37/9} 26. a4 {+1.25/8} b5 {-0.23/9} 27.
axb5 {+1.56/9} axb5 {-0.06/8} 28. Bd3 {+1.05/9} b4 {+0.04/9} 29.
Qb2+ {+0.83/9} Rf6 30. Bc4 {+1.00/9} Ra7 {+0.10/9} 31. Re4 {+1.00/9}
Bf5 {+0.25/9} 32. Re3 {+0.90/10} Rc7 {+0.24/9} 33. Bb3 {+0.90/10}
h6 {+0.04/9} 34. Rfe1 {+1.20/9} Kh7 {+0.00/10} 35. Qd4 {+1.21/9}
Rf7 {-0.07/10} 36. Qh4 {+1.18/10} g5 {+0.02/9} 37. Qh5 {+1.37/9}
Kg7 {+0.00/9} 38. Qd1 {+1.32/8} Kh7 {+0.00/8} 39. Qd4 {+1.38/8}
Rf6 {-0.08/9} 40. Qd1 {+1.43/8} Rf7 {+0.00/9} 41. Qd4 {+1.41/9}
Rf6 {+0.00/13} 42. Bd1 {+1.45/9} Bg6 {+0.11/9} 43. Bf3 {+1.39/10}
Bf5 {-0.15/10} 44. h4 {+1.40/9} Kg8 {-0.15/9} 45. hxg5 {+1.23/10}
hxg5 {-0.12/9} 46. Re5 {+1.55/9} b3 {-0.19/8} 47. Kg1 {+1.82/9}
Rb7 {-0.11/9} 48. Qb2 {+1.87/10} g4 {+0.00/10} 49. Bd1 {+1.77/10}
g3 {-0.22/9} 50. fxg3 {+1.82/9} Bd3 {-0.22/8} 51. Kh2 {+1.86/8}
Rh6+ {+0.05/8} 52. Kg1 {+1.47/8} Rf6 {+0.00/10} 53. Rg5+ {+1.83/8}
Rg6 {+0.00/9} 54. Ree5 {+1.81/9} Qf6 {+0.00/9} 55. Rxg6+ {+1.74/9} Bxg6 56.
g4 {+1.42/9} Qxe5 {+3.39/9} 57. Qxe5 {-2.12/12} b2 {+4.69/12} 58.
Qe6+ {-2.12/11} Kh7 {+4.87/12} 59. Bc2 {+0.00/12} Bxc2 {+7.53/11} 60.
Qf7+ {+0.00/10}
{Typhoon crashed!} *

Anyway, best regards,
Guenther

Hi Guenther,

The problem seems to be EGTB related. I get get no errors running
Typhoon with EGTB's off, but with EGTB's on I get the same error as you when entering the endgame.

Regards,
Jim.

The old pawn hash was one giant table that used a multi probe and lock system. It was good for 2 cpu MP machines but beyond that the contention for pawn hash entries slowed down the engine in parallel searches.

Around version 225 or so I took the pawn hash table and put it into the searcher thread context. This basically means that each searcher thread has its own copy of the pawn hash.

This has an obvious drawback in that less information is shared between threads -- each thread has to populate its own pawnhash. It also means using more memory in the process.

On the upside this means that there is no locking required in the pawn hash table which speeds up the engine on machines with more than 2 cpus. It should have no affect on single proc machines.

Yes, the --pawnhash commandline option went away. I think I allocate something like 64Mb per searcher thread as a pawn hash table. I'll make this configurable again sometime soon.

Scott

The reason for the stack overflow is that there were a couple of places where SEARCHER_THREAD_CONTEXT structs were stack allocated. Of course when I added the pawn hash table to each searcher thread context, this blows the stack. I fixed all these errors that I know of in the revision after the pawn hash change -- I'd recommend synching up to the latest revision. If this doesn't fix the crash email me directly and I'll debug it.

Thx,
Scott

Well, I knew giving out the engine would be a good move in terms of finding bugs and improving its strength...

Here's the deal: there were 2 bugs. The first one made EGTB accesses crash the engine on gcc builds. I didn't see this because my main testing machine uses MSVC. For the curious: I defined TB_FASTCALL as a real gcc fastcall in one place and Eugene Nalimov's EGTB probe code defines it as a noop in another place. The calling code in probe.c was using a different calling convension than the function it was calling in Eugene's egtb.cpp file. This is fixed.

While I was looking at this I stumbled across another bug in the interior node recognizers that was calling class of positions "won" when it was really a draw. This is also fixed.

While I was in the egtb code I updated it to the latest code from Eugene / crafty. I don't know if there are any other bugfixes in this update but probably there are.

The only thing that is moderately "experimental" in the latest checkin (i.e. not a bugfix) is some stuff Bob Hyatt was talking about that involves the conditions about when to split the tree in a parallel search. It seems to make little or no difference in the strength of play; more testing is forthcoming.

Thanks for reporting the bugs; sorry to everyone with crashes!
The latest revision is 233.

Scott

Thanks for fixing all of this Scott!
It seems you are working quite a lot on Typhoon
since the last weeks

Regards,
Guenther

Hi Scott,

Here's the new gcc-cygwin builds for revision 233. (Will be on my homepage tonight.)

Egtb support fix confirmed - no crashes here, thanks.
Still getting stackdump error on exit though.

http://www.orbitfiles.com/download/id520117091

Out of interest, whats the 'Tord Romstad' connection with Typhoon?

Tord's name appears as co/author when you load the engine into Arena (the country flag looks suspiciously Scandinavian as well) .
His name also appears on the 'Todo' notes.

Regards,
Jim.

I made a Linux executable and run into the following problems.

I edited the Makefile:

Code: Select all

CPUTYPE         =   athlon-xp

however, while copiling gcc always said:

Code: Select all

gcc -pipe -DPROFILE="\"-std=gnu99 -D_X86_ -O3 -march=pentium ...

There was a compiler error:

Code: Select all

util.o: In function `ReadNextGameFromPgnFile':util.c:(.text+0x46c): undefined reference to `errno'

solved with a hammer:

Code: Select all

//            Trace("fgets failed, errno=%u.\n", errno);


The executable starts and again:

Code: Select all

$Id: chess.h 232 2006-07-24 18:29:17Z scott $
    GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)
    Make profile used: -std=gnu99 -D_X86_ -O3 -march=pentium

It uses ~150MB RAM although using only 32 MB hash:

Code: Select all

white(1): dump sizes
sizeof(PAWN_HASH_ENTRY). . . . . . . . . 84 bytes
sizeof(HASH_ENTRY) . . . . . . . . . . . 16 bytes
sizeof(MOVE) . . . . . . . . . . . . . . 4 bytes
sizeof(ATTACK_BITV). . . . . . . . . . . 4 bytes
sizeof(SQUARE) . . . . . . . . . . . . . 8 bytes
sizeof(POSITION) . . . . . . . . . . . . 1428 bytes
sizeof(MOVE_STACK) . . . . . . . . . . . 233992 bytes
sizeof(PLY_INFO) . . . . . . . . . . . . 424 bytes
sizeof(COUNTERS) . . . . . . . . . . . . 244 bytes
sizeof(SEARCHER_THREAD_CONTEXT). . . . . 61605760 bytes
sizeof(GAME_OPTIONS) . . . . . . . . . . 1132 bytes
sizeof(MOVE_TIMER) . . . . . . . . . . . 40 bytes
sizeof(PIECE_DATA) . . . . . . . . . . . 16 bytes
sizeof(VECTOR_DELTA) . . . . . . . . . . 4 bytes
sizeof(GAME_PLAYER). . . . . . . . . . . 16 bytes
sizeof(GAME_HEADER). . . . . . . . . . . 64 bytes
sizeof(GAME_MOVE). . . . . . . . . . . . 60 bytes
sizeof(GAME_DATA). . . . . . . . . . . . 72 bytes
sizeof(SEE_LIST) . . . . . . . . . . . . 196 bytes
sizeof(BOOK_ENTRY) . . . . . . . . . . . 36 bytes
-------------------------------------------------
Current main hash table size . . . . . . 33554432 bytes (~32 Mb)


I tried 230 in a tournament and took it out because ~50% of the games simply finished without result. No error messages or something usefull in the log files.

I'll try this version again and will report.

Volker

Hi Volker,

I edited the Makefile:

Code:
CPUTYPE = athlon-xp


however, while copiling gcc always said:

Code:
gcc -pipe -DPROFILE="\"-std=gnu99 -D_X86_ -O3 -march=pentium ...

Should be 2 makefiles there - 'makefile' (for bsd) and 'gnumakefile'
You're probably editing one, but running the other.
Suggestion: delete 'makefile', rename 'gnumakefile' to 'makefile'
and edit and use that one.

It uses ~150MB RAM although using only 32 MB hash:

You can have a smaller memory footprint by editing 'chess.h'.
Use these values for 65mb footprint.

Code: Select all

#define EVAL_HASH_TABLE_SIZE (699050) // was  32Mb (per thread) 2097152

#define PAWN_HASH_TABLE_SIZE (43690) // was 5.5Mb (per thread)  131072


There was a compiler error:

Code:
util.o: In function `ReadNextGameFromPgnFile':util.c:(.text+0x46c): undefined reference to `errno'


solved with a hammer:

Code:
// Trace("fgets failed, errno=%u.\n", errno);

If you don't have a hammer handy add this line to beginning of 'util.c'

Code: Select all

#include <errno.h>


Regards,
Jim.

Jim Ablett wrote:Egtb support fix confirmed - no crashes here, thanks.
Still getting stackdump error on exit though.

That's a stange one probably related to the orderly shutdown of threads. I'll think about it.

Jim Ablett wrote:Out of interest, whats the 'Tord Romstad' connection with Typhoon?

Tord's name appears as co/author when you load the engine into Arena (the country flag looks suspiciously Scandinavian as well) .
His name also appears on the 'Todo' notes.

I have no idea why this would be. His name appears in a comment in search.c next to one of his ideas. He suggested a refinement to the LMR idea that I use; his name in search.c and TODO are related to this. I don't know why that makes him a co-author, though. Bob Hyatt, Ed Shroder and Bruce Moreland also have their names in various comments next to their ideas...

Scott