AEGT questions

[Daniel Shawul]

Geschrieben von:/Posted by: Daniel Shawul at 24 August 2004 05:52:05:


is EGTB a must? if so, i can only download 3 & 4 man egtb from
arena.
if i can only give 64MB for hashtables and the engine uses
pawnhash, can i give the engine the full 64MB and

[Daniel Shawul]

Geschrieben von:/Posted by: Daniel Shawul at 24 August 2004 06:23:35:
Als Antwort auf:/In reply to: AEGT questions geschrieben von:/posted by: Daniel Shawul at 24 August 2004 05:52:05:

is EGTB a must? if so, i can only download 3 & 4 man egtb from
arena.
if i can only give 64MB for hashtables and the engine uses
pawnhash, can i give the engine the full 64MB and i want to do this because if i 50MB for main hashtable,it will use the next
number 32MB,and pawn hash will also be 32MB,which i don't think is good.
if anybody in the bishop class chooses the 2nd otption , let me know.
daniel

forget the first one. I have manged to download the 3,4 egtbs

[Ross Boyd]

Geschrieben von:/Posted by: Ross Boyd at 24 August 2004 06:45:27:
Als Antwort auf:/In reply to: Re: AEGT questions geschrieben von:/posted by: Daniel Shawul at 24 August 2004 06:23:35:

is EGTB a must? if so, i can only download 3 & 4 man egtb from
arena.
if i can only give 64MB for hashtables and the engine uses
pawnhash, can i give the engine the full 64MB and >i want to do this because if i 50MB for main hashtable,it will use the next
number 32MB,and pawn hash will also be 32MB,which i don't think is good.
if anybody in the bishop class chooses the 2nd otption , let me know.
daniel

forget the first one. I have manged to download the 3,4 egtbs

Hi Daniel,
I was going to say that TRACE relies on EGTB for some endgames. It probably won't affect the result too much. She usually loses before the endgame.
With 64Mb max available I would configure TRACE as follows...
Edit the XXXXX.cfg file (where XXXXX is the actual name of the executable, eg. TRACE130.EXE would create/use a file called TRACE130.cfg in the same directory/folder as the executable)
Then set the following values in this order...
// Main transposition size in MB (silently rounds down to a power of 2)
hash 32
// Size of pawn hash in MB ( silently rounds down)
hashp 8
// The path of the EGTB folder
egpath c:\tb
// The MBytes to use for EGTB cache.
// Usable values are 1..64 (At least 8 is good)
egsize 16
// Resign when score is X pawns down for a few moves in a row...
resign 6
// Thats it...

Hope that helps...
Ross

[Olivier Deville]

Geschrieben von:/Posted by: Olivier Deville at 24 August 2004 07:05:05:
Als Antwort auf:/In reply to: Re: AEGT questions geschrieben von:/posted by: Daniel Shawul at 24 August 2004 06:23:35:

is EGTB a must? if so, i can only download 3 & 4 man egtb from
arena.
if i can only give 64MB for hashtables and the engine uses
pawnhash, can i give the engine the full 64MB and >i want to do this because if i 50MB for main hashtable,it will use the next
number 32MB,and pawn hash will also be 32MB,which i don't think is good.
if anybody in the bishop class chooses the 2nd otption , let me know.
daniel

forget the first one. I have manged to download the 3,4 egtbs

Hello Daniel
3 and 4 men EGTB are fine, and in this case, 4mb cache will be enough. We decided that in case 64mb are allowed, pawnhash must fit within these 64mb (example : Crafty, 48mb main hash and 24mb pawnhash). But we made a few exceptions, and TRACE is one of them If the engine needs only a few mb of pawnhash, they are granted.
Olivier


ChessWar + AEGT

[Olivier Deville]

Geschrieben von:/Posted by: Olivier Deville at 24 August 2004 07:13:11:
Als Antwort auf:/In reply to: Re: AEGT questions geschrieben von:/posted by: Ross Boyd at 24 August 2004 06:45:27:

is EGTB a must? if so, i can only download 3 & 4 man egtb from
arena.
if i can only give 64MB for hashtables and the engine uses
pawnhash, can i give the engine the full 64MB and >>i want to do this because if i 50MB for main hashtable,it will use the next
number 32MB,and pawn hash will also be 32MB,which i don't think is good.
if anybody in the bishop class chooses the 2nd otption , let me know.
daniel

forget the first one. I have manged to download the 3,4 egtbs

Hi Daniel,
I was going to say that TRACE relies on EGTB for some endgames. It probably won't affect the result too much. She usually loses before the endgame.
With 64Mb max available I would configure TRACE as follows...
Edit the XXXXX.cfg file (where XXXXX is the actual name of the executable, eg. TRACE130.EXE would create/use a file called TRACE130.cfg in the same directory/folder as the executable)
Then set the following values in this order...
// Main transposition size in MB (silently rounds down to a power of 2)
hash 32
// Size of pawn hash in MB ( silently rounds down)
hashp 8
// The path of the EGTB folder
egpath c:\tb
// The MBytes to use for EGTB cache.
// Usable values are 1..64 (At least 8 is good)
egsize 16
// Resign when score is X pawns down for a few moves in a row...
resign 6
// Thats it...

Hope that helps...
Ross

Hi Ross
I have used the following config file for TRACE in AEGT, I hope this is correct
Olivier
//
// TRACE Winboard Chess Engine - Configuration File
//
// CONFIGURATION NOTES:
// ====================
// You may edit this file to configure the TRACE engine
// Lines beginning with // are comments...
//
// NB. You may specify any number of WB commands and they will
// be processed in sequential order. Use 'help' to list
// the available commands and syntax.
// ===========================================================
// The Transposition Table size in MBytes. (MANDATORY)
// Usable values are 0,1,2,4,8,16,32,64,128,256,512
// For best results don't specify sizes that cause constant disk access
// Use hash 0 to switch transposition probing OFF.
hash 64
// The Pawn Hash Table size in MBytes.
// Usable values are 0,1,2,4,7,14,28
// Use hashp 0 to switch pawn hashing OFF.
hashp 4
// The path(s) of the Endgame Table folder(s)
// This must appear BEFORE the egsize is specified.
// NB. Separate multiple paths with a semicolon (;)
egpath c:\TBs
// The EGTB cache size in MBytes. (MANDATORY)
// Usable values are 0..64 (8 or higher is good)
// Use egsize 0 to switch EGTB probing OFF
egsize 8
// Set the Resign threshold to pawns.
// Note that TRACE will only resign after 4 consecutive moves are
// below the threshold AND its not a mating sequence
// Use resign 0 to switch resignation OFF.
// A good value is 6 ie. resign when behind by 6 pawns
resign 8



ChessWar + AEGT

[Daniel Shawul]

Geschrieben von:/Posted by: Daniel Shawul at 24 August 2004 09:33:22:
Als Antwort auf:/In reply to: Re: AEGT questions geschrieben von:/posted by: Ross Boyd at 24 August 2004 06:45:27:

is EGTB a must? if so, i can only download 3 & 4 man egtb from
arena.
if i can only give 64MB for hashtables and the engine uses
pawnhash, can i give the engine the full 64MB and >>i want to do this because if i 50MB for main hashtable,it will use the next
number 32MB,and pawn hash will also be 32MB,which i don't think is good.
if anybody in the bishop class chooses the 2nd otption , let me know.
daniel

forget the first one. I have manged to download the 3,4 egtbs

Hi Daniel,
I was going to say that TRACE relies on EGTB for some endgames. It probably won't affect the result too much. She usually loses before the endgame.
With 64Mb max available I would configure TRACE as follows...
Edit the XXXXX.cfg file (where XXXXX is the actual name of the executable, eg. TRACE130.EXE would create/use a file called TRACE130.cfg in the same directory/folder as the executable)
Then set the following values in this order...
// Main transposition size in MB (silently rounds down to a power of 2)
hash 32
// Size of pawn hash in MB ( silently rounds down)
hashp 8
// The path of the EGTB folder
egpath c:\tb
// The MBytes to use for EGTB cache.
// Usable values are 1..64 (At least 8 is good)
egsize 16
// Resign when score is X pawns down for a few moves in a row...
resign 6
// Thats it...

Hope that helps...
Ross

Hi Ross
i used the exact copy of Oliver's setting , but if you prefer this
new setting i can do it, trace hasn't started its games yet.

best
daniel

[Ross Boyd]

Geschrieben von:/Posted by: Ross Boyd at 24 August 2004 13:08:38:
Als Antwort auf:/In reply to: Re: AEGT questions geschrieben von:/posted by: Daniel Shawul at 24 August 2004 09:33:22:

is EGTB a must? if so, i can only download 3 & 4 man egtb from
arena.
if i can only give 64MB for hashtables and the engine uses
pawnhash, can i give the engine the full 64MB and >>>i want to do this because if i 50MB for main hashtable,it will use the next
number 32MB,and pawn hash will also be 32MB,which i don't think is good.
if anybody in the bishop class chooses the 2nd otption , let me know.
daniel

forget the first one. I have manged to download the 3,4 egtbs

Hi Daniel,
I was going to say that TRACE relies on EGTB for some endgames. It probably won't affect the result too much. She usually loses before the endgame.
With 64Mb max available I would configure TRACE as follows...
Edit the XXXXX.cfg file (where XXXXX is the actual name of the executable, eg. TRACE130.EXE would create/use a file called TRACE130.cfg in the same directory/folder as the executable)
Then set the following values in this order...
// Main transposition size in MB (silently rounds down to a power of 2)
hash 32
// Size of pawn hash in MB ( silently rounds down)
hashp 8
// The path of the EGTB folder
egpath c:\tb
// The MBytes to use for EGTB cache.
// Usable values are 1..64 (At least 8 is good)
egsize 16
// Resign when score is X pawns down for a few moves in a row...
resign 6
// Thats it...

Hope that helps...
Ross

Hi Ross
i used the exact copy of Oliver's setting , but if you prefer this
new setting i can do it, trace hasn't started its games yet.

best
daniel

I'm not sure what settings Olivier used but for a 64Mb limit the above is quite acceptable to me.
Thanks Daniel,
Ross

[Ross Boyd]

Geschrieben von:/Posted by: Ross Boyd at 24 August 2004 13:16:09:
Als Antwort auf:/In reply to: Re: AEGT questions geschrieben von:/posted by: Olivier Deville at 24 August 2004 07:13:11:

is EGTB a must? if so, i can only download 3 & 4 man egtb from
arena.
if i can only give 64MB for hashtables and the engine uses
pawnhash, can i give the engine the full 64MB and >>>i want to do this because if i 50MB for main hashtable,it will use the next
number 32MB,and pawn hash will also be 32MB,which i don't think is good.
if anybody in the bishop class chooses the 2nd otption , let me know.
daniel

forget the first one. I have manged to download the 3,4 egtbs

Hi Daniel,
I was going to say that TRACE relies on EGTB for some endgames. It probably won't affect the result too much. She usually loses before the endgame.
With 64Mb max available I would configure TRACE as follows...
Edit the XXXXX.cfg file (where XXXXX is the actual name of the executable, eg. TRACE130.EXE would create/use a file called TRACE130.cfg in the same directory/folder as the executable)
Then set the following values in this order...
// Main transposition size in MB (silently rounds down to a power of 2)
hash 32
// Size of pawn hash in MB ( silently rounds down)
hashp 8
// The path of the EGTB folder
egpath c:\tb
// The MBytes to use for EGTB cache.
// Usable values are 1..64 (At least 8 is good)
egsize 16
// Resign when score is X pawns down for a few moves in a row...
resign 6
// Thats it...

Hope that helps...
Ross

Hi Ross
I have used the following config file for TRACE in AEGT, I hope this is correct
Olivier
//
// TRACE Winboard Chess Engine - Configuration File
//
// CONFIGURATION NOTES:
// ====================
// You may edit this file to configure the TRACE engine
// Lines beginning with // are comments...
//
// NB. You may specify any number of WB commands and they will
// be processed in sequential order. Use 'help' to list
// the available commands and syntax.
// ===========================================================
// The Transposition Table size in MBytes. (MANDATORY)
// Usable values are 0,1,2,4,8,16,32,64,128,256,512
// For best results don't specify sizes that cause constant disk access
// Use hash 0 to switch transposition probing OFF.
hash 64
// The Pawn Hash Table size in MBytes.
// Usable values are 0,1,2,4,7,14,28
// Use hashp 0 to switch pawn hashing OFF.
hashp 4
// The path(s) of the Endgame Table folder(s)
// This must appear BEFORE the egsize is specified.
// NB. Separate multiple paths with a semicolon (;)
egpath c:\TBs
// The EGTB cache size in MBytes. (MANDATORY)
// Usable values are 0..64 (8 or higher is good)
// Use egsize 0 to switch EGTB probing OFF
egsize 8
// Set the Resign threshold to pawns.
// Note that TRACE will only resign after 4 consecutive moves are
// below the threshold AND its not a mating sequence
// Use resign 0 to switch resignation OFF.
// A good value is 6 ie. resign when behind by 6 pawns
resign 8

Hi Olivier,
The above config allows TRACE to use 76Mb of RAM. If that is within the AEGT rules then the above setting is fine. But see my previous reply to Daniel for a setting that will use less than 64Mb.
Best wishes,
Ross

[Ross Boyd]

Geschrieben von:/Posted by: Ross Boyd at 24 August 2004 13:20:22:
Als Antwort auf:/In reply to: Re: AEGT questions geschrieben von:/posted by: Olivier Deville at 24 August 2004 07:05:05:

is EGTB a must? if so, i can only download 3 & 4 man egtb from
arena.
if i can only give 64MB for hashtables and the engine uses
pawnhash, can i give the engine the full 64MB and >>i want to do this because if i 50MB for main hashtable,it will use the next
number 32MB,and pawn hash will also be 32MB,which i don't think is good.
if anybody in the bishop class chooses the 2nd otption , let me know.
daniel

forget the first one. I have manged to download the 3,4 egtbs

Hello Daniel
3 and 4 men EGTB are fine, and in this case, 4mb cache will be enough. We decided that in case 64mb are allowed, pawnhash must fit within these 64mb (example : Crafty, 48mb main hash and 24mb pawnhash). But we made a few exceptions, and TRACE is one of them
Olivier

That was nice of someone!
Forget my other posts about the config file. It seems Olivier's settings are quite okay for TRACE.

If the engine needs only a few mb of pawnhash, they are granted.

Cheers!
Ross

[Olivier Deville]

Geschrieben von:/Posted by: Olivier Deville at 24 August 2004 13:22:14:
Als Antwort auf:/In reply to: Re: AEGT questions geschrieben von:/posted by: Ross Boyd at 24 August 2004 13:08:38:

is EGTB a must? if so, i can only download 3 & 4 man egtb from
arena.
if i can only give 64MB for hashtables and the engine uses
pawnhash, can i give the engine the full 64MB and >>>>i want to do this because if i 50MB for main hashtable,it will use the next
number 32MB,and pawn hash will also be 32MB,which i don't think is good.
if anybody in the bishop class chooses the 2nd otption , let me know.
daniel

forget the first one. I have manged to download the 3,4 egtbs

Hi Daniel,
I was going to say that TRACE relies on EGTB for some endgames. It probably won't affect the result too much. She usually loses before the endgame.
With 64Mb max available I would configure TRACE as follows...
Edit the XXXXX.cfg file (where XXXXX is the actual name of the executable, eg. TRACE130.EXE would create/use a file called TRACE130.cfg in the same directory/folder as the executable)
Then set the following values in this order...
// Main transposition size in MB (silently rounds down to a power of 2)
hash 32
// Size of pawn hash in MB ( silently rounds down)
hashp 8
// The path of the EGTB folder
egpath c:\tb
// The MBytes to use for EGTB cache.
// Usable values are 1..64 (At least 8 is good)
egsize 16
// Resign when score is X pawns down for a few moves in a row...
resign 6
// Thats it...

Hope that helps...
Ross

Hi Ross
i used the exact copy of Oliver's setting , but if you prefer this
new setting i can do it, trace hasn't started its games yet.

best
daniel

I'm not sure what settings Olivier used but for a 64Mb limit the above is quite acceptable to me.
Thanks Daniel,
Ross

Ross, I used 64mb for main hash and 4mb for pawnhash, this was accepted by the AEGT team. TB cache doesn't need to be included in the sum, we grant 4mb for 3 & 4 men and 8mb for 3, 4 and 5 men.
Olivier



ChessWar + AEGT

[Olivier Deville]

Geschrieben von:/Posted by: Olivier Deville at 24 August 2004 15:04:04:
Als Antwort auf:/In reply to: Re: AEGT questions geschrieben von:/posted by: Ross Boyd at 24 August 2004 13:16:09:

is EGTB a must? if so, i can only download 3 & 4 man egtb from
arena.
if i can only give 64MB for hashtables and the engine uses
pawnhash, can i give the engine the full 64MB and >>>>i want to do this because if i 50MB for main hashtable,it will use the next
number 32MB,and pawn hash will also be 32MB,which i don't think is good.
if anybody in the bishop class chooses the 2nd otption , let me know.
daniel

forget the first one. I have manged to download the 3,4 egtbs

Hi Daniel,
I was going to say that TRACE relies on EGTB for some endgames. It probably won't affect the result too much. She usually loses before the endgame.
With 64Mb max available I would configure TRACE as follows...
Edit the XXXXX.cfg file (where XXXXX is the actual name of the executable, eg. TRACE130.EXE would create/use a file called TRACE130.cfg in the same directory/folder as the executable)
Then set the following values in this order...
// Main transposition size in MB (silently rounds down to a power of 2)
hash 32
// Size of pawn hash in MB ( silently rounds down)
hashp 8
// The path of the EGTB folder
egpath c:\tb
// The MBytes to use for EGTB cache.
// Usable values are 1..64 (At least 8 is good)
egsize 16
// Resign when score is X pawns down for a few moves in a row...
resign 6
// Thats it...

Hope that helps...
Ross

Hi Ross
I have used the following config file for TRACE in AEGT, I hope this is correct
Olivier
//
// TRACE Winboard Chess Engine - Configuration File
//
// CONFIGURATION NOTES:
// ====================
// You may edit this file to configure the TRACE engine
// Lines beginning with // are comments...
//
// NB. You may specify any number of WB commands and they will
// be processed in sequential order. Use 'help' to list
// the available commands and syntax.
// ===========================================================
// The Transposition Table size in MBytes. (MANDATORY)
// Usable values are 0,1,2,4,8,16,32,64,128,256,512
// For best results don't specify sizes that cause constant disk access
// Use hash 0 to switch transposition probing OFF.
hash 64
// The Pawn Hash Table size in MBytes.
// Usable values are 0,1,2,4,7,14,28
// Use hashp 0 to switch pawn hashing OFF.
hashp 4
// The path(s) of the Endgame Table folder(s)
// This must appear BEFORE the egsize is specified.
// NB. Separate multiple paths with a semicolon (;)
egpath c:\TBs
// The EGTB cache size in MBytes. (MANDATORY)
// Usable values are 0..64 (8 or higher is good)
// Use egsize 0 to switch EGTB probing OFF
egsize 8
// Set the Resign threshold to pawns.
// Note that TRACE will only resign after 4 consecutive moves are
// below the threshold AND its not a mating sequence
// Use resign 0 to switch resignation OFF.
// A good value is 6 ie. resign when behind by 6 pawns
resign 8

Hi Olivier,
The above config allows TRACE to use 76Mb of RAM. If that is within the AEGT rules then the above setting is fine. But see my previous reply to Daniel for a setting that will use less than 64Mb.
Best wishes,
Ross

76mb is quite acceptable. I wrote the following to AEGT team a month ago. My point of view was accepted by the other testers.
Olivier

"We voted that the pawnhash must be included in the total hash allowed (eg. 64mb).

This is quite logical for Crafty (48mb mainhash + 24mb pawnhash).

Some authors are asking only a few pawnhash : for example, Trace.cfg suggests 64mb mainhash and 4mb pawnhash. And it takes around 80mb in memory with these settings - some engines are more greedy when you give them only 64mb of mainhash, and they don't tell you what the extra mb used are for.

I would rather give Trace 64mb mainhash and 4mb pawnhash. We certainly can give instead 32mb mainhash and 28mb pawnhash, because we voted this way. Trace takes 73mb this way, but I have the feeling that giving so much pawnhash would be a waste."



ChessWar + AEGT

[Dan Honeycutt]

Geschrieben von:/Posted by: Dan Honeycutt at 24 August 2004 20:29:07:
Als Antwort auf:/In reply to: Re: AEGT questions geschrieben von:/posted by: Olivier Deville at 24 August 2004 15:04:04:

[snip] some engines are more greedy when you give them only 64mb of mainhash, and they don't tell you what the extra mb used are for.

Hi Olivier:
Apologies for being one of those greedy engines that grabs memory without telling what it's used for. For anyone wishing to know exact values I'll gladly send you the source (all dynamic memory allocation is done by InitMem() in main.cpp and InitHash() in hash.cpp) but here's what you'll find:
Bruja 1.8 allocates about a meg for it's rotated attack boards, move list, history heuristics and assorted other arrays. For hash tables it allocates 196608 bytes for pawn hash, 16384 bytes for repetition hash and the mb specified in the .ini file (default 16 mb) for transposition hash. Version 1.7 which you are using was more greedy and allocated about another meg for pre-computed static exchange calculations but this cache-unfriendly array is now gone.
Best Regards
Dan H.

[Ross Boyd]

Geschrieben von:/Posted by: Ross Boyd at 25 August 2004 00:25:07:
Als Antwort auf:/In reply to: Re: AEGT questions geschrieben von:/posted by: Dan Honeycutt at 24 August 2004 20:29:07:

[snip] some engines are more greedy when you give them only 64mb of mainhash, and they don't tell you what the extra mb used are for.

Hi Olivier:
Apologies for being one of those greedy engines that grabs memory without telling what it's used for. For anyone wishing to know exact values I'll gladly send you the source (all dynamic memory allocation is done by InitMem() in main.cpp and InitHash() in hash.cpp) but here's what you'll find:
Bruja 1.8 allocates about a meg for it's rotated attack boards, move list, history heuristics and assorted other arrays. For hash tables it allocates 196608 bytes for pawn hash, 16384 bytes for repetition hash and the mb specified in the .ini file (default 16 mb) for transposition hash. Version 1.7 which you are using was more greedy and allocated about another meg for pre-computed static exchange calculations but this cache-unfriendly array is now gone.
Best Regards
Dan H.

Hi Dan,
Interesting... I really like the way Bruja plays. It seems to have a great knack for getting its pieces into attacking positions. It also appears to prefer longer time controls. I have a theory that attack tables tend to pay off at longer time controls... but could be mistaken.
The last few days I started designing TRACE 2 (a rewrite) and the things high on the wishlist are king safety and attack tables. Ed's pre-calculated SEE approach is very enticing but as you say its not cache friendly. Also, it doesn't hold info about xrays and pins.
In my 1.31 beta I tried Crafty's king safety approach as a proof of concept and it really helped a lot, but I would prefer to evaluate pressure on a square by square basis.
Anyway, gotta run,
Ross

[Ross Boyd]

Geschrieben von:/Posted by: Ross Boyd at 25 August 2004 02:05:48:
Als Antwort auf:/In reply to: Re: AEGT questions geschrieben von:/posted by: Ross Boyd at 25 August 2004 00:25:07:

Hi Dan,
Interesting... I really like the way Bruja plays. It seems to have a great knack for getting its pieces into attacking positions. It also appears to prefer longer time controls. I have a theory that attack tables tend to pay off at longer time controls... but could be mistaken.
The last few days I started designing TRACE 2 (a rewrite) and the things high on the wishlist are king safety and attack tables. Ed's pre-calculated SEE approach is very enticing but as you say its not cache friendly. Also, it doesn't hold info about xrays and pins.
In my 1.31 beta I tried Crafty's king safety approach as a proof of concept and it really helped a lot, but I would prefer to evaluate pressure on a square by square basis.

By square by square I'm referring to Ed's evaluation of the squares surrounding the king. In contrast Crafty's approach is driven more by pawn defects and general piece tropism. In comparison, I think Ed's approach can overlook xrays/pins and Bob's approach can misevaluate the power of a distant bishop/queen on a strong diagonal... but they are both far and away better than the static scoring that TRACE currently uses.
Its funny, when I started TRACE in late 2002 it was based on TSCP and my goal was to speed everything up.. so I redesigned the data structures to use 0x88, hashing etc and hence achieve a higher search depth. That was enough to become a weak midrange engine. Tweaks to eval, qsearch and extensions have made it a midrange midrange engine.
Now, the chief goal is to design an engine where movegen speed is not the overriding factor... rather, that the data structures carry more useful information regarding each piece's influence. And although maintaining this data carries a high overhead, the advantages are that pruning methods become more refined, SEE becomes faster and more accurate (pin detection), king safety is vastly improved, move ordering improves, check detection is instant, movegen legality increases, and so on...
Anyway, my waffle detector just went off so I'd better stop here...
One more thing, watching Bruja at the WBEC is fascinating. Bruja has achieved three 4-0 scores in 6 rounds! Amazing! I think that's partly due to Bruja's excellent piece play. It knows how to build a good attacking position. Well done.
Best regards,
Ross

[Olivier Deville]

Geschrieben von:/Posted by: Olivier Deville at 25 August 2004 11:00:24:
Als Antwort auf:/In reply to: Re: AEGT questions geschrieben von:/posted by: Dan Honeycutt at 24 August 2004 20:29:07:

[snip] some engines are more greedy when you give them only 64mb of mainhash, and they don't tell you what the extra mb used are for.

Hi Olivier:
Apologies for being one of those greedy engines that grabs memory without telling what it's used for. For anyone wishing to know exact values I'll gladly send you the source (all dynamic memory allocation is done by InitMem() in main.cpp and InitHash() in hash.cpp) but here's what you'll find:
Bruja 1.8 allocates about a meg for it's rotated attack boards, move list, history heuristics and assorted other arrays. For hash tables it allocates 196608 bytes for pawn hash, 16384 bytes for repetition hash and the mb specified in the .ini file (default 16 mb) for transposition hash. Version 1.7 which you are using was more greedy and allocated about another meg for pre-computed static exchange calculations but this cache-unfriendly array is now gone.
Best Regards
Dan H.

Hi Dan
Many thanks for the information! I don't need your source code, as I am unable to read such stuff The few extra mb are no problem at all.
Olivier



ChessWar + AEGT

[Dan Honeycutt]

Geschrieben von:/Posted by: Dan Honeycutt at 25 August 2004 19:28:53:
Als Antwort auf:/In reply to: Re: AEGT questions geschrieben von:/posted by: Ross Boyd at 25 August 2004 02:05:48:

Hi Dan,
Interesting... I really like the way Bruja plays. It seems to have a great knack for getting its pieces into attacking positions. It also appears to prefer longer time controls. I have a theory that attack tables tend to pay off at longer time controls... but could be mistaken.
The last few days I started designing TRACE 2 (a rewrite) and the things high on the wishlist are king safety and attack tables. Ed's pre-calculated SEE approach is very enticing but as you say its not cache friendly. Also, it doesn't hold info about xrays and pins.
In my 1.31 beta I tried Crafty's king safety approach as a proof of concept and it really helped a lot, but I would prefer to evaluate pressure on a square by square basis.

By square by square I'm referring to Ed's evaluation of the squares surrounding the king. In contrast Crafty's approach is driven more by pawn defects and general piece tropism. In comparison, I think Ed's approach can overlook xrays/pins and Bob's approach can misevaluate the power of a distant bishop/queen on a strong diagonal... but they are both far and away better than the static scoring that TRACE currently uses.
Its funny, when I started TRACE in late 2002 it was based on TSCP and my goal was to speed everything up.. so I redesigned the data structures to use 0x88, hashing etc and hence achieve a higher search depth. That was enough to become a weak midrange engine. Tweaks to eval, qsearch and extensions have made it a midrange midrange engine.
Now, the chief goal is to design an engine where movegen speed is not the overriding factor... rather, that the data structures carry more useful information regarding each piece's influence. And although maintaining this data carries a high overhead, the advantages are that pruning methods become more refined, SEE becomes faster and more accurate (pin detection), king safety is vastly improved, move ordering improves, check detection is instant, movegen legality increases, and so on...
Anyway, my waffle detector just went off so I'd better stop here...
One more thing, watching Bruja at the WBEC is fascinating. Bruja has achieved three 4-0 scores in 6 rounds! Amazing! I think that's partly due to Bruja's excellent piece play. It knows how to build a good attacking position. Well done.
Best regards,
Ross

Hi Ross:
Bruja has done well so far in WBEC. Problem is, there's this other engine which has done a little better
My precomputed exchange table (Basically Ed's scheme which I used for SEE and King Safety) did include x-ray attacks but these had to be ordered to work. Ie a pawn could be followed by a bishop or queen of the same color, a rook could be followed by another rook or queen etc. I found I could do it on the fly just as fast (it would seem that a table lookup should be faster than the calculation thus I figure it must be a cache issue) plus I get a little better accuracy for the x-ray attacks. I now do this like Crafty and take a look behind each piece as it enters the fray.
But my main reason for discarding the table is that I want to try adding pins. Dr. Hyatt has said in CCC that it didn't do Crafty any good so he discarded
it. However, I can do pins at basically half price - I do legal move generation so at any time I have (or can use) the pin data for one side. Having pin data for both sides at all times also opens up the possibility of using it for evaluation. Since you are also looking at keeping pin data I'd be interested to know how it does for you.
Somewhat against my better judgement, I wish you good luck in WBEC.
Dan H.

[Ross Boyd]

Geschrieben von:/Posted by: Ross Boyd at 26 August 2004 09:13:12:
Als Antwort auf:/In reply to: Re: AEGT questions geschrieben von:/posted by: Dan Honeycutt at 25 August 2004 19:28:53:

Hi Dan,
Interesting... I really like the way Bruja plays. It seems to have a great knack for getting its pieces into attacking positions. It also appears to prefer longer time controls. I have a theory that attack tables tend to pay off at longer time controls... but could be mistaken.
The last few days I started designing TRACE 2 (a rewrite) and the things high on the wishlist are king safety and attack tables. Ed's pre-calculated SEE approach is very enticing but as you say its not cache friendly. Also, it doesn't hold info about xrays and pins.
In my 1.31 beta I tried Crafty's king safety approach as a proof of concept and it really helped a lot, but I would prefer to evaluate pressure on a square by square basis.

By square by square I'm referring to Ed's evaluation of the squares surrounding the king. In contrast Crafty's approach is driven more by pawn defects and general piece tropism. In comparison, I think Ed's approach can overlook xrays/pins and Bob's approach can misevaluate the power of a distant bishop/queen on a strong diagonal... but they are both far and away better than the static scoring that TRACE currently uses.
Its funny, when I started TRACE in late 2002 it was based on TSCP and my goal was to speed everything up.. so I redesigned the data structures to use 0x88, hashing etc and hence achieve a higher search depth. That was enough to become a weak midrange engine. Tweaks to eval, qsearch and extensions have made it a midrange midrange engine.
Now, the chief goal is to design an engine where movegen speed is not the overriding factor... rather, that the data structures carry more useful information regarding each piece's influence. And although maintaining this data carries a high overhead, the advantages are that pruning methods become more refined, SEE becomes faster and more accurate (pin detection), king safety is vastly improved, move ordering improves, check detection is instant, movegen legality increases, and so on...
Anyway, my waffle detector just went off so I'd better stop here...
One more thing, watching Bruja at the WBEC is fascinating. Bruja has achieved three 4-0 scores in 6 rounds! Amazing! I think that's partly due to Bruja's excellent piece play. It knows how to build a good attacking position. Well done.
Best regards,
Ross

Hi Ross:
Bruja has done well so far in WBEC. Problem is, there's this other engine which has done a little better
My precomputed exchange table (Basically Ed's scheme which I used for SEE and King Safety) did include x-ray attacks but these had to be ordered to work. Ie a pawn could be followed by a bishop or queen of the same color, a rook could be followed by another rook or queen etc. I found I could do it on the fly just as fast (it would seem that a table lookup should be faster than the calculation thus I figure it must be a cache issue) plus I get a little better accuracy for the x-ray attacks. I now do this like Crafty and take a look behind each piece as it enters the fray.
But my main reason for discarding the table is that I want to try adding pins. Dr. Hyatt has said in CCC that it didn't do Crafty any good so he discarded
it. However, I can do pins at basically half price - I do legal move generation so at any time I have (or can use) the pin data for one side. Having pin data for both sides at all times also opens up the possibility of using it for evaluation. Since you are also looking at keeping pin data I'd be interested to know how it does for you.
Somewhat against my better judgement, I wish you good luck in WBEC.
Dan H.

Its a neck and neck race... with an exciting finish, I hope.
Writing cache friendly code is very strange isn't it... your optimizing instincts tell you the big table lookup MUST be faster... but its not. Ack!
Yes, I read that thread. It probably is more accurate but too cpu-hungry to be effective. I agree with you. If it can be done efficiently it should help an engine avoid some gross mis-evaluations.
This is all very topical for me. In TRACE 2 one of the design clauses is that pins/xray data be readily available for a) legal move generation b) generating checks c) eval of dangerous pins d) SEE accuracy
The difficult part is minimising the work. One approach, (which I haven't yet tested) is to set all of a ply's pin data to a value PIN_UNKNOWN and then calculate the pins on an as-needed basis... perhaps this would avoid some work... IOW, do you really need to calculate all of them up front?
I don't know the answer to this yet...
Oh, it'll be fun whatever the result. I don't know what's going to happen when they meet. 2-2 would be fine by me.
Good luck!
Ross