Author: Vincent Diepeveen
Date: 09:17:50 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"... I'm doing that faster too. Yes with something that you would call a bitboard. But i do it in 32 bits. Noop i'm not a GNU program, so i don't post source here. >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. Yes 8 bits is faster, i think i mentionned it several times that i slowed down my program by removing all 8 bits arrays. For the same reason 32 bits is than 64 bits! >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. Why use so many inline assembly then if quality is what you care for and/or mix 8 bits with 32 bits and 64 bits if quality is what you care for? >> >>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_. This is not true. Suppose we have Bd2 a4 Bc1 a3 Kg2 Now search lines are like: Bd2 a4 Bc1 a3 Kg2 Bd2 a4 Bc1 a3 Kg1 Bd2 a4 Bc1 a3 Kg3 Bd2 a4 Bc1 a3 Kh3 Bd2 a4 Bc1 a3 Kh2 Bd2 a4 Bc1 a3 Kh1 Bd2 a4 Bc1 a3 Kf1 Bd2 a4 Bc1 a3 Kf2 So if you can do something easy as PSQ incremental that's hell faster. I agree with you that when things get hard to have an overview over that it's getting tougher. But problem here is that you also SUFFER in evaluation unneccesarily 2 branch misprediction penalties from around 20 to 25 clocks in this case (worst case because branch is a tough branch, so not the minimum of 10 clocks each). So that's a waste of 50 clocks in all the above search lines, ONLY for bishops. Not to mention the clocks it takes to count them! >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... No that's not true at all. If you search that deep then the only thing which matters is good evaluation. I do loads more as you do :) >> >>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". In chess both count. I have both.
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.