Author: Vincent Diepeveen
Date: 09:07:52 05/31/01
Go up one level in this thread
On May 31, 2001 at 09:02:22, Brian Richardson 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] > >I think this is actually to support multiprocessing with different tree >pointer values yes it is. >>/ >>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. > >You might be overlooking that with the bitmap >if( (something[indexed]&bitmask) == pattern ) >can also find ALL occurances of something, not just >one square at a time This is true. That's why i use similar stuff for pawnstructures if it is faster for me. But not a 64 bits bitboard :) Because we must not forget that in all these patterns there are a load of instructions extra here because it's seen by compiler as 2x32 bits. So extra instructions are needed! >> > >> >>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! >> >>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 !! >I did some testing with incremental piece square updates v >in from scratch in the eval function. >Incremental was slower (there are way more >moves made than eval function calls). Also, it becomes >harder to use different values based dynamically on the phase of the >game. Your implementation sucks bigtime then or you never evaluate. What Bob is doing in bitboards is pretty slow in evaluation. At least 1 misprediction penalty is involved too. In makemove/unmakemove you do not suffer that in my datastructure because i do a general lookup. This is peanut for Bob to make. Nothing as cheap as incrementally doing things instead of recounting all pieces every evaluation! >> >>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! >> >>Overall i'm amazed crafty plays that strong with so little evaluation! > >It was my impression that Crafty was not intended to rely on raw speed, >but in fact does have extensive evaluation, tuned to play stronger >humans, not computers > >> >>Probably tuning of it has been done at a very professional level! >> >>Best Regards, >>Vincent > >Brian Richardson
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.