Author: Andrew Dados
Date: 13:19:05 05/31/01
Go up one level in this thread
On May 31, 2001 at 10:37:25, Robert Hyatt wrote: >On May 31, 2001 at 08:09:52, Vincent Diepeveen wrote: > >>Hello i had in mind comparing assembly output of 2 things >>but now i look in crafty 18.9 i see the pattern is not even >>in crafty 18.9, though it's a basic pattern. so it's hard >>to compare things. >> >>But i'm pretty amazed by that every thing is >>getting referenced as >> tree->pos.board[sq] >> >>If i would be roman catholic i would now make a cross and say >>"lucky i'm multiprocessor", >> >>because what i would be using there is >> board[sq] >> >>And i'm using that everywhere in my evaluation. Bob >>however smartly got rid of the thing by using a define >>that however translatest to it PcOnSq() it's called. >> >>But in the assembly code you still see it! >> >>Also what i see is the general problem of bitboards: >> if( (something[indexed]&bitmask) == pattern ) >> >>Where i can do >> if( something[indexed] == pattern ) >> >>So i save an AND there. > >come on. Show me your one if to see if a pawn is isolated. Or if it is >passed. Or if it is passed and can't be caught by the opposing king. Or >if your two rooks or rook/queen are connected on the 7th rank... or if you >have the "absolute 7th"... > >you are comparing apples to oranges... > > > >> >>Also i'm pretty amazed by 'signed char bval_w[64]'. >> >>First of all in DIEP i am happy to announce that i threw out all >>8 bits arrays. >> >>I didn't know crafty is still using 8 bits arrays! >>I thought it was a mixture of 32 bits with 64 bits! > > >Vincent, I suspect there is a _lot_ you don't know. :) I use them because >they are faster on the Intel hardware. The test to prove it is quite simple. >64 bytes is 2 cache lines. 64 words is 8 cache lines. It's just that simple. > > > >> >>The second thing i wonder about is why this is getting done *every* >>evaluation. bval_w gives a piece square table value which is constant >>for bishops. >> >>You can do that incremental in makemove/unmakemove !! > > >Have you read my reasons for doing this in the past? Apparently not. So >one more time: > >"I do everything in evaluate.c to make it easy to change the code. If I do >things incrementally, then I have to modify _two_ pieces of code when I change >it. Modifying one thing is easier. I'm worried less about speed than I am >about quality. I don't know, for example, that the bishop piece/square table >will always exist. In fact, I am pretty sure it won't. > > > > >> >>This is a pure waste of system time! >> >>Note in DIEP i would do that in my makemove as: >> int *p; >> global int tablescore; >> p = psq[piece]; >> >> tablescore += p[to_square]-p[from_square]; >> >>Crafty does it every evaluation!!! >> >>Bob something to improve in your evaluation! > >Nope. One day as pieces of the evaluation become "static" and don't change >anymore, some of it _might_ get done incrementally. But in endgames, your >"idea" is not so good. Suppose you move your bishop twice in the search path? >You evaluate that piece/square entry _twice_. I evaluate it _once_. > >The deeper the depth, the less effective that incremental stuff is. Just try >it on Fine #70 for example. I'll toast you good there... > [snip] Bob I saw that reasoning few times already and I thing you are wrong here. Suppose branching factor of 2 and suppose we use that evaluation code on every ply you will get spent time: const*(1+1/2+1/4+1/8+...)~<=2*const; I can write it like that because time spent in eval 3 plys deep from leaves will be destributed among 8 children. so *in worst case* you will have 2 times cost of normal leaf eval. However most paths would give you const*(0+0+1/4+0+1/16+...) or sth like that. So incremental eval cost is comparable to 'each leaf eval' no matter how many plys. With BF of 3 worst case would give you 0.5 more time spent in incremental eval (1/3+1/9+1/27+...=0.5). While it is hard to estimate average case (path) I think incremental eval will still outperform 'each leaf eval'. And the worse the BF the better incremental eval gets. -Andrew-
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.