Attack table

Programming Topics (Computer Chess) and technical aspects as test techniques, book building, program tuning etc

Moderator: Andres Valverde

Re: Attack table

Postby Dan Honeycutt » 21 Oct 2004, 03:03

Hi Zach (and others):

I figured I'd get a rise out of someone with an O(n) bubble sort. My sort:

Code: Select all
void SortBubble(s_move *pm1, s_move *pm2, int num) {
  int swap;
  s_move  temp, *pm;
  pm2--;    //last move
  while (pm1 < pm2) {
    pm = pm2;
    swap = FALSE;
    while (pm > pm1) {
      if (pm->val > (pm-1)->val) {
        temp = *pm;
        *pm = *(pm-1);
        *(pm-1) = temp;
        swap = TRUE;
      }
      pm--;
    }
    num--;
    if (!swap || !num) return;
    pm1++;
  }
}


If I'm sorting root moves or a short list of captures I'll call it with num=0 and it is a standard bubble sort. But for normal search all moves I call it with num=5 or so.

We could argue best way to sort till the cows come home, but I figure, like Sune, if I'm not going to get a cutoff in the first few moves I'm not going to get one at all. My method actually produces a few less nodes than a full sort. This puzzled me at first till I figured out what was going on. With a full sort the losing captures went down to the rock bottom of the list. With a partial sort they end up around the middle of the list. Due to SEE inaccuracys some of those losing captures aren't really losing and they produce more cutoffs than other do-nothing moves.

Dan H.
Dan Honeycutt
 
Posts: 167
Joined: 28 Sep 2004, 15:49
Location: Atlanta Georgia, USA

Re: Attack table

Postby Sune Fischer » 21 Oct 2004, 03:19

Hi Uri

Yes the quality of moves gets worse it gets practicly random, but it doesn't matter as much because with a very high probability we can say that none of them will be good enough for a cutoff.

To put it bluntly, either the first move cuts off or none of them will!
Not exactly true of course, but with good move ordering it's not that far from the truth.

If our elaborate sorting scheme with hashmove, winners, killers and the like have not been able to find a move good enough for a cutoff, chances are slim that the remaining sorting methods can do any better in finding the right move.

There are those who say speed is not important and that reducing tree size is all one should worry about, but I think this is one of those situations where a balanced optimization is required ;)

-S.
User avatar
Sune Fischer
 
Posts: 126
Joined: 07 Oct 2004, 11:12
Location: Denmark

Re: Attack table

Postby Uri Blass » 21 Oct 2004, 03:58

Hi Sune

I disagree.

ordering moves make sense even when the remaining depth is small if you have a good order.

The advantage is that you can decide to prune and not to search part of the moves in that case.

Uri
User avatar
Uri Blass
 
Posts: 727
Joined: 09 Oct 2004, 05:59
Location: Tel-Aviv

Re: Attack table

Postby Reinhard Scharnagl » 21 Oct 2004, 09:57

Hello all,

during the last hours I have tried to go away from the more philosophical points of view. Thus I have started some tests to make a statistic of the influence of sorting to the average time it costs to provide a single move. The problem in my Smirf generator is, that it combines a more detailed evaluation with sorting. Without sorting only the material gain is calculated. Nevertheless ignoring that detail I believe the results are very usable to estimate the factor sorting (doing it the way Smirf does it).
Code: Select all
moves/node          additional time
1                   0
7                   1/4
17                  1/2
50                  1
140                 2
290                 3   (10x8 board)

It would be interesting to have comparable results.

Reinhard.
Reinhard Scharnagl
 
Posts: 608
Joined: 01 Oct 2004, 08:36
Location: Klein-Gerau, Germany

Re: Attack table

Postby Uri Blass » 21 Oct 2004, 10:11

Hi Reinhard.
I do not understand your statistics.

What are the units of your statistics?

Additional time 3 tells me nothing if I do not know 3 of what and what is the original time when you do not sort the moves.

I also do not understand moves/node

I doubt if there are many practical positions with 290 legal moves even in 8*10 board.

Uri
User avatar
Uri Blass
 
Posts: 727
Joined: 09 Oct 2004, 05:59
Location: Tel-Aviv

Re: Attack table

Postby Reinhard Scharnagl » 21 Oct 2004, 10:17

Hi Uri,

sorry to have myself expressed such ambiguous.

The numbers should show a factor which gives the additional time consumption per move when sorting is affected.

At a given set of nodes with move count n:

factor(n) = average (time(generating sorted)/time(generating unsorted)) - 1

Reinhard.

P.S.:
a) sorry for editing/correcting my text later
b) the example with 290 moves still is a good testing example concerning sort, to ajust the approximation curve to its maximum of usage.
Reinhard Scharnagl
 
Posts: 608
Joined: 01 Oct 2004, 08:36
Location: Klein-Gerau, Germany

Re: Attack table

Postby Uri Blass » 21 Oct 2004, 10:35

Not sure if I understand.
You have for example the line
50 1

I understand that the 1 means that you are twice slower in generating moves because of sorting.

I am not sure about the meaning of 50.
Does it mean that you need to sort 50 moves?

practically in search you do not have constant number of legal moves so how do you check it?

Uri
User avatar
Uri Blass
 
Posts: 727
Joined: 09 Oct 2004, 05:59
Location: Tel-Aviv

Re: Attack table

Postby Reinhard Scharnagl » 21 Oct 2004, 10:59

Hi Uri,
(50, 1) I understand that the 1 means that you are twice slower in generating moves because of sorting.
I am not sure about the meaning of 50. Does it mean that you need to sort 50 moves

absolutly that for both! This implicates that Smirf's move generator with sorting (and positional preevaluating) in pratice would need about 3/4 more time than being used without that type of sort. I estimate the generator to produce between 20 and 30 million sorted moves a second (P4 2.8 GHz). So why should I think about sorting or not and install a maybe also time consuming decision procedure whether to sort or not to sort.
practically in search you do not have constant number of legal moves so how do you check it?

Because Smirf is always sorting, it does not need to know that number. To get the result I have posted I have made a series of to be expanded positions and tried to find an approximating curve through that statistic.

Reinhard.

P.S.: let me add a link to a testing run of my sorted move generator: http://www.chessbox.de/Down/CRC_Test_02.txt
Reinhard Scharnagl
 
Posts: 608
Joined: 01 Oct 2004, 08:36
Location: Klein-Gerau, Germany

Re: Attack table

Postby Sune Fischer » 21 Oct 2004, 11:29

Hi Uri,

Uri Blass wrote:I disagree.

ordering moves make sense even when the remaining depth is small if you have a good order.

The advantage is that you can decide to prune and not to search part of the moves in that case.


I prune heavily on the last plies as well but I do not find move ordering to be needed for this.

-S.
User avatar
Sune Fischer
 
Posts: 126
Joined: 07 Oct 2004, 11:12
Location: Denmark

Re: Attack table

Postby Sune Fischer » 21 Oct 2004, 11:39

Hi Reinhard,

Reinhard Scharnagl wrote:This implicates that Smirf's move generator with sorting (and positional preevaluating) in pratice would need about 3/4 more time than being used without that type of sort. I estimate the generator to produce between 20 and 30 million sorted moves a second (P4 2.8 GHz). So why should I think about sorting or not and install a maybe also time consuming decision procedure whether to sort or not to sort.


I think perhaps we aren't quite talking about the same thing here, sorting 20 million moves per second would leave no time for anything else in the engine.
I guess you mean that you assign scores to 20 million moves a second?

This would sound more plausible, although I think it can be optimized because it is not needed in every case. E.g. when you have a hash move don't spend time generating or sorting any moves, just search the hashmove first and see where it brings you.

-S.
User avatar
Sune Fischer
 
Posts: 126
Joined: 07 Oct 2004, 11:12
Location: Denmark

Re: Attack table

Postby Uri Blass » 21 Oct 2004, 11:52

I also prune in the last plies but I think that good move ordering not for the first moves can probably help to improve it when it is possible to prune more with the same risk.

Uri
User avatar
Uri Blass
 
Posts: 727
Joined: 09 Oct 2004, 05:59
Location: Tel-Aviv

Re: Attack table

Postby Reinhard Scharnagl » 21 Oct 2004, 11:52

Hi Sune,

I estimate the generator to produce between 20 and 30 million sorted moves a second (P4 2.8 GHz).

what has been unclear within this sentence? How much moves does your generator produce (sorted / unsorted)?

E.g. when you have a hash move don't spend time generating or sorting any moves ...

You are substituting a sort by a) checking that situation b) searching a hash move c) when this was not successful handling a unsorted and partially invalid move list. Why making things that complicated? Sorting will bring hash- and killer-moves in front (within Smirf).

Reinhard.
Reinhard Scharnagl
 
Posts: 608
Joined: 01 Oct 2004, 08:36
Location: Klein-Gerau, Germany

Re: Attack table

Postby Sune Fischer » 21 Oct 2004, 12:16

Hi Uri,

Uri Blass wrote:I also prune in the last plies but I think that good move ordering not for the first moves can probably help to improve it when it is possible to prune more with the same risk.


Yes I always do move ordering for the first couple of moves, but I have managed to empiricly convince myself that sorting all moves is too expensive to be worth while.

Once I get to that stage where I realize this node is 99% sure of failing low I stop with the ordering, pruning individual moves is now allowed if conditions x,y and z are fulfilled.

-S.
User avatar
Sune Fischer
 
Posts: 126
Joined: 07 Oct 2004, 11:12
Location: Denmark

Re: Attack table

Postby Uri Blass » 21 Oct 2004, 12:22

Hi Reinhard,

Movei during a game generate between 10 and 15 million moves per second on A3000.

The moves are unsorted except the first 10 moves.

Note that I believe that it is possible to improve movei by reducing the number and I generate all the legal moves after every make move in almost every case because I have no function to generate only captures.

Uri
User avatar
Uri Blass
 
Posts: 727
Joined: 09 Oct 2004, 05:59
Location: Tel-Aviv

Re: Attack table

Postby Uri Blass » 21 Oct 2004, 12:31

Sune Fischer wrote:Hi Uri,

Uri Blass wrote:I also prune in the last plies but I think that good move ordering not for the first moves can probably help to improve it when it is possible to prune more with the same risk.


Yes I always do move ordering for the first couple of moves, but I have managed to empiricly convince myself that sorting all moves is too expensive to be worth while.

Once I get to that stage where I realize this node is 99% sure of failing low I stop with the ordering, pruning individual moves is now allowed if conditions x,y and z are fulfilled.

-S.


I also do similiar things but I think that with good move ordering you can replace x,y,z by the fact that the moves are low in the list and also saving checking conditions x y z for the remaining moves.

Uri
User avatar
Uri Blass
 
Posts: 727
Joined: 09 Oct 2004, 05:59
Location: Tel-Aviv

Re: Attack table

Postby Sune Fischer » 21 Oct 2004, 12:36

Reinhard Scharnagl wrote:what has been unclear within this sentence? How much moves does your generator produce (sorted / unsorted)?


I don't know many moves it can produce a second, I'm trying to produce as few moves as possible so big numbers are bad for me. ;)

None of the moves come out with scores and there is no sorting.

These functions remain independent of the generator because I need flexibility to do different things at different plies. Move ordering and scoring is more accurate at the high interior nodes and gets more and more quick as we approach the leaves. This gives the best trade off on speed vs. tree size.

E.g. when you have a hash move don't spend time generating or sorting any moves ...

You are substituting a sort by a) checking that situation b) searching a hash move c) when this was not successful handling a unsorted and partially invalid move list. Why making things that complicated? Sorting will bring hash- and killer-moves in front (within Smirf).
Reinhard.


This is all about which is faster. Let's consider the possible cases.

a) you have a move list of 40 moves and you fail-high within 5 moves with ~99% chance (on move 1.3 on average?).

b) you have a move list of 40 moves and you fail-low.

c) remaining type nodes, with good ordering this 0.5% of the nodes.

(correct me if I'm wrong).

Sorting a full list of 40 moves with O(n logn) for n=40 will require about 212 conditionals and a great deal of shuffling moves around.

This is not free and it it practicly wasted in both cases a) and b), only in case c) is it worth while.

The relevant question here is, I think, why optimize for the 1% case and not for the other 99% of cases?

-S.
User avatar
Sune Fischer
 
Posts: 126
Joined: 07 Oct 2004, 11:12
Location: Denmark

Re: Attack table

Postby Reinhard Scharnagl » 21 Oct 2004, 12:43

Hi Uri,
Movei during a game generate between 10 and 15 million moves per second on A3000.

wow! That are numbers for the ENGINE (not for the move generator)! Thus a) your generator itself must be very fast; b) if the quality of the generated moves would be good (what I definitly prosume), it would never be possible for Smirf to compete; c) within an engine move generating results are less relevant, e.g. whether you sort or substitute sorting by other means, and because of doing a lot of other things like detail / positional evaluating (what obviously and probably would cost Smirf the most of the time consumed).
... because I have no function to generate only captures

So Smirf also cannot, but I have a function to speed up when only refuting a check threat being a mate or not by finding few legal answers only.

Reinhard.
Reinhard Scharnagl
 
Posts: 608
Joined: 01 Oct 2004, 08:36
Location: Klein-Gerau, Germany

Re: Attack table

Postby Sune Fischer » 21 Oct 2004, 12:46

Hi Uri,

I also do similiar things but I think that with good move ordering you can replace x,y,z by the fact that the moves are low in the list and also saving checking conditions x y z for the remaining moves.


Well I think it amounts to the same :)

You probably apply conditions x,y,z to your sorting process in some way to make the bottom moves "prunable", so it's a question of semantics really.

You can see my implementation as an O(n) sorting device which kicks in when conditions are ripe.

Actually I think my implementation is a bit faster because there is no suffling of moves on the list, futile moves are simply deleted. ;)

-S.
User avatar
Sune Fischer
 
Posts: 126
Joined: 07 Oct 2004, 11:12
Location: Denmark

Re: Attack table

Postby Reinhard Scharnagl » 21 Oct 2004, 12:57

Hi Sune,

may be it is simply because I have another kind of "philosophy". I estimate the futil fully to be expanded nodes to be about 50%, where sorting may be wasted time (to what I am not sure, because of earlier creating better informed nodes inside the transposition table). The remaining 50% will for sure profit from being ordered. To inspect the move list for good moves until a sufficiently valued move would be found could be far more time expensive than ordering all en block. I think the effort to make a picking the remaining best preevaluated move is an O(n^2) procedure. Thus I believe that the complete 100% ordering process efforts may need about the same time. But in both cases the TT probably would be filled earlier with more relevant information.

Reinhard.
Reinhard Scharnagl
 
Posts: 608
Joined: 01 Oct 2004, 08:36
Location: Klein-Gerau, Germany

Re: Attack table

Postby Sune Fischer » 21 Oct 2004, 13:07

Hi Reinhard,

Hehe, well I must say I don't agree much.

But oh well, there is not much point in discussing this further I think, the test to see which is better for the engine is fortunately very easy to do.

-S.
User avatar
Sune Fischer
 
Posts: 126
Joined: 07 Oct 2004, 11:12
Location: Denmark

PreviousNext

Return to Programming and Technical Discussions

Who is online

Users browsing this forum: Majestic-12 [Bot] and 18 guests