Author: Robert Hyatt
Date: 13:53:08 05/31/01
Go up one level in this thread
On May 31, 2001 at 12:07:52, Vincent Diepeveen wrote: >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! Why don't we just run crafty and diep on the same hardware, and set the hardware performance monitor to measure how effectively each uses the two integer pipes in the CPU. You might discover those "extra" instructions are sucked up by the second pipe, while you aren't using it very effectively if you have lots of dependencies. Suddenly those "extra" instructions are "gone". > >>> >> >>> >>>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! You are aware that I don't recount all pieces for every evaluation? In fact, I do it for less than 10% of the total Evaluation() calls done... You can't do "lazy incremental update". I can do "lazy 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.