Author: Russell Reagan
Date: 10:58:44 09/29/04
Go up one level in this thread
On September 29, 2004 at 08:27:29, martin fierz wrote: >>My guess is that you, just like the rest of us, don't know *exactly* what you >>want to do. >wrong. i know exactly what i want. perhaps i will change my mind and want >something different, but for the moment i know what i want. i want a fast >framework of movegen, hashing, repcheck etc. which also has all attacks handy at >every node. >this last part is by far the most expensive, and that is why i am bothering >y'all with questions about fast attack generation. I wouldn't say this is describing *exactly* what you want. You're wanting something general, not something specific (at least what you describe in this post). For instance, what does it mean to have "all attacks handy at every node"? If you want a bitboard attack table, then any approach will do, and changing approaches is much easier. If you want on-the-fly attack generation, then the optimal approach depends on how you plan to use the attack bitboards. Rotated bitboards take a square and generate attacks in all directions from that single square. KoggeStone takes a bitboard and generates attacks from each set bit in a single direction. They take different inputs and produce different outputs. Which one is best depends how you plan to use them, which depends on knowing **exactly** what you want to do. If you do SEE exactly like Crafty, then rotated bitboards will do well. Maybe you can think of a more clever method using KoggeStone. You have to know those details before you know which is best for you. That's what I meant about trying to write something that can do everything as fast as possible. If you want something that can generate generic attacks in any situation, then it may be somewhat fast in all situations, but less than optimal in some situations (like KoggeStone and ray-tracing, depends whether the position is open or closed). There is nothing you can do about that unless you know ***exactly*** what you want to do :) If you don't know the details of what you want to do, all you can do is plan for change (flexible, modifiable, abstract code). It sounds like you want a bitboard attack table, not on-the-fly attack generation. If you aren't doing on-the-fly attack generation, you just need some routine to regenerate attack bitboards at every node, and changing such a function from rotated bitboards to KoggeStone or ray tracing is a relatively minor change when you restrict it to only a handful of functions. I'd guess no more than three functions would need to be modified. >>>surprise! after __forceinline, it got clearly faster but still slower then the >>>written-out version. >> >> >>What compiler? > >visual C++ 2005 express beta. > > >cheers > martin Hmmm. Have you run the test with something non-beta? I can't recall any time when inline functions produced slower code than macros since I've been using MSVC .NET 2003 Pro. You can get the command line compiler for free if you don't have it. Or if you post your test code or send it to me I will run the comparison and play with the compiler settings for a while. I bet the inline function version will not be slower (even without __forceinline).
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.