Author: Robert Hyatt
Date: 07:37:25 05/31/01
Go up one level in this thread
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... > >Overall i'm amazed crafty plays that strong with so little evaluation! > >Probably tuning of it has been done at a very professional level! > >Best Regards, >Vincent Don't confuse "quantity" with "quality".
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.