Author: Uri Blass
Date: 06:56:17 01/06/04
Go up one level in this thread
On January 06, 2004 at 09:35:54, Robert Hyatt wrote: >On January 05, 2004 at 16:39:04, Uri Blass wrote: > >>I see that crafty is using swap_list[32] and I think that the array is too long. >> >>There are only 8 queen directions and 8 knight directions and I think that for >>practical cases swap_list[16] can make Crafty faster with no problems(in theory >>it is possible that 16 is not enough but I do not imagine a practical case when >>it can happen. > >How would it make it faster? I only use the part of the list that is >actually necessary. The question is if allocating memory does not cost speed. > >Also, shortening the list will wreck things for those that set up oddball >positions. It is certainly possible to have 16 pieces for each side attacking >a single square, since my Swap() understands "x-ray attacks" where two pieces >are in battery along a rank/file/diagonal. I need 32 to handle the worst case >of both sides having 9 queens, two rooks, two bishops, two knights and a king >attacking the target square... The bishops cannot attack the same square so the worst case is 30 pieces It is practically even less because it is impossible to promote pawns to queens without some captures and only 2 pawns can attack the same square. > >> >>I wonder if it is not better to have swap_list[16] in Crafty and add >>if (nc==15) break if you want to be careful not to crash maybe in 1 out of 1000 >>games. > >Again, I'm not sure how that would help. I only use the first few entries in >normal positions. Just like my move list can theoretically hold a thousand >moves for one side even though that can never be reached. There is a difference if you have global varaibles or local varaibles. int swap[32] is a local varaible and I thought that the computer waste time in allocating memory to the local varaibles every time that you call it but maybe the computer does not work in that way thanks to some compiler optimiazation. > > > > >> >>It seems to me that the price of allocating memory to 16 integer is higher than >>the price of one if (nc==15) inside the loop. > >16 integers is 1/2 of a cache line. 32 is exactly one line, except that there >is no alignment forced to make the starting address exactly divisible by 128. > > > > >> >> >>Another point that I see is that it is using the value of the pieces and does >>not use piece square table. > >Correct. That will also simply confuse results. This is intended to be a >simple material-only estimate of "is the capture good or bad?" > > > >> >>I wonder if there is a reason not to use piece square table to evaluate capture >>of pawn in the 7th as better than capture of pawn in the second rank. >> >>Uri > >That would probably wreck the basic SEE concept. And pawns on the 7th don't >have much of a piece/square number for Crafty, so it really won't make any >difference for me. The point that I thought about is better order of captures. Even small difference in piece square table can generate better order of captures. Uri
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.