Author: Wylie Garvin
Date: 17:03:41 12/11/01
Go up one level in this thread
On December 09, 2001 at 05:17:49, Sune Fischer wrote: >On December 08, 2001 at 22:54:36, Wylie Garvin wrote: >>>How are you doing it? >>> >>>-S. >> >>Well, first of all I'm writing the interesting parts of my program in 80x86 >>assembly, so my method may not be general enough for everybody. ;) > >Sounds very ambitious ;) > Thanks, it is...since this is a hobby rather than a job or something, I can afford to tackle projects with a high probability of failure. =) >>However, my observation is that at the time you GENERATE moves you know what >>kind of move you are generating; > >Precisely, so I put that information into the move sort of like this: > >move.typeofmove = WCastleQ; or >move.typeofmove = BEnPassent; > >then I can call the correct move rutine without checking a thing: > >pMakeMove[move.typeofmove](Position,move); >where pMakeMove is an array of pointers to my move functions. > >Don't know if it is faster though, assembler is lots faster for sure. > One thing to watch out for is, calling functions through pointers can be slow on some kinds of machines. For example, on Intel it will be slow unless the compiler can predict well in advance which actual function you are going to call (or unless you are calling the same one like 90% of the time). Course it may not matter at a spot like this; you wouldn't want to do it in your attack generation though. >> so I differentiate them into two categories. >>There are the "normal" moves, which simply means "if dest is non-empty, remove >>captured piece. Then move source to dest." Notice that the vast majority of >>moves fit into this category. I use the bottom 12 bits (0-11) for the source >>and dest squares, and bit 12 to indicate that a move is a "special" move. > >Okay, that helps, as long as you don't have a huge switch case or if else if >structure you need to check everytime ;) No switches or anything. My makemove routine does not do anything different for different kinds of pieces on non-special moves (even pawns and kings get moved the same as everything else). I.e. there are no branches in my makemove after it decides the move is not special. I take that back; there is *one* branch (after mostly moving the new piece on top of the old, it does one test to see if the target was formerly empty and if not it branches off to "remove" the old piece). > >>And why did I decide to write it all in assembly?? Well, (more than any other >>reason) because it's fun. Also I can do some things that no C compiler can, >>like take full advantage of Intel's bit-scan and bit-manipulation instructions >>which have been fast since the Pentium II. My code will be A LOT smaller, and >>hopefully a lot faster, than that generated by any C compiler, because I know >>exactly what's going on in there and carefully juggle registers, etc. for >>maximum effect. > >I'm getting the impression that this is almost 100% assembly you are writing, if >so that is a bit overkill I think. Critical parts will benefit a lot obviously. > Oh, it's definitely overkill. OTOH, I expect my entire chess engine to be <16K of code when it's done. Except that I'm going to write the root-node oracles and things in C, at risk of some bloat. For example, the code I've written to detect the ends of sliding-piece rays (for detecting checks or generating captures) or enumerate the squares up to the end of each ray (for generating non-captures) totals up to around 600 bytes. I.e. the size of some C compilers' hello-world. >>Of course there are some optimizations that I probably can't do >>as well as a strong compiler, such as instruction scheduling, especially since >>P2/P3/P4 have some different requirements. A major worry is that sometimes you >>forget one single optimization principle (such as alignment of certain labels) >>and the whole thing runs 15% slower. But I have VTune and someday when I have a >>whole working engine, I'll go back and work harder on the parts where my code >>gets punished the most. =) > >Sounds great, but what about portability? >Are you using any of those new instruction sets like SSE or 3DNow! ? >oh, I should mention, I don't know the first thing about assembler ;) > Yeah, portability is out the window. That's no problem--when something else replaces Intel as the dominant desktop machine, I'll just write a new one. =) I am making some minimal use of MMX instructions for manipulating 64-bit zobrist keys and bitboards, but so far it appears to be faster to just use integer registers. The main places where I expected them to come in handy (calculating attack bitboards and such) seem to have gone away in favor of BSF/BSR type stuff... >>cheers, >>wylie > > >P.S. sorry for the double post.
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.