Author: Sune Fischer
Date: 15:57:38 04/23/02
Go up one level in this thread
On April 23, 2002 at 14:03:00, Uri Blass wrote: >On April 23, 2002 at 11:20:55, Sune Fischer wrote: > >>On April 23, 2002 at 10:55:30, Russell Reagan wrote: >> >>>On April 23, 2002 at 05:03:42, Sune Fischer wrote: >>> >>>>In contrary to what many people suggests, I think one should not completely >>>>ignore optimizations. If you give it no thought at all, you quickly stand to >>>>lose a factor of 10 or worse. >>>>Things like generating the entire movelist and then sorting the entire movelist >>>>by some simple O(N^2) algorithm, and doing all this with a huge array being >>>>allocated on the fly is real bad, it will cost a lot of performance. >>> >>>I think this is more under the heading of choosing better algorithms like other >>>people have suggested rather than minute decisions of whether to pass pointers >>>to all of your functions or whether to use global data. >>> >>>You're right though, choosing the best algorithms and making wise decisions from >>>the beginning will get you a good efficient program. I think when people talk >>>about optimization they mean taking a good efficient program and tweaking >>>existing sections a bit to squeeze out a little more speed. >>> >>>For example, using a piece array to avoid having to loop through 64 squares >>>(instead using 16 or fewer iterations vs. 64 iterations) isn't really considered >>>an optimization as much as it is simply a good idea, or maybe a "correct" or >>>"not wrong" idea. >>> >>>Russell >> >>Yes, that's what I meant, when you decide on the algorithm and structures, do it >>also with respect to speed. Do give the issue _some_ attention, or else you >>certainly will be paying that factor of 10-100 in penalty, and rewriting the >>whole shamole later is not that fun either. > >In my case the algorithm of generating move is complicated so writing and >rewriting again seems to me the best idea. > >If you write the complicated algporithm first then searching for bugs is a >bigger problem. > >Uri But you have written quite a complex movegenerator with special attacktables, and you optimized this by a factor 100 by doing it incrementally? And you did this before your program was 2300 elo also, right? So basicly you decided to optimize for speed before you had a strong engine, which means you wanted speed before hashtables and nullmove and all the other stuff that would also have made your engine powerful. I'm not saying that is a bad thing, in fact that is pretty much how I'm doing it, I don't want a 2200 engine where the design has reached its limits and the whole thing needs rewriting. To name another example, my first "move" was a struct with to and from square and type of piece etc. I thought this was easier than compacting everything into an unsigned int. I now changed it to the compact notation, it is _much_ faster when you add moves to the stack, when you swap moves on the stack or if you want to compare two moves. Everything is done with a few macros, so I wouldn't even say the code is more complex. I also made the foolish choice that the squares should go from 1 to 64 instead of 0-63, and lots of other little unpractical things like that. I regret not having made better choices from the beginning, it was a pain to rewrite it. Not all things are that nasty to rewrite of cource. -S.
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.