Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Bitboard board representation

Author: Dann Corbit

Date: 17:10:27 01/13/05

Go up one level in this thread


On January 13, 2005 at 19:40:26, Eric Oldre wrote:

>On January 13, 2005 at 18:47:02, Dann Corbit wrote:
>
>>On January 13, 2005 at 18:07:19, Eric Oldre wrote:
>>[snip]
>>>I guess this news is bitter sweet, no need to re-code a big part of my engine.
>>>But no cheap gains in speed to be had either.
>
>When I wrote this what I meant was that I wouldn't get a cheap gain from this
>particular issue, not that there aren't many other parts of my code that could
>be optimized.
>
>>
>>Do you have a profiler?
>
>I had been using compuware devpartner last summer, but then i reformatted my
>machine and haven't gotten around to reinstalling it. Latista is really overdue
>to be profiled.
>
>>
>>The Intel profiler is the best I have seen, but even the free Gprof will give
>>you valueable information.
>>
>
>Maybe I should download the intel profiler, can it profile code compiled with
>MSVC 2003? Or only code compiled with the intel compiler?

It works for both.  It's quite expensive, but you can use it for a trial period
for free, I think.

>>If you want to find out where the time is going, a profiler is a very profitable
>>step.
>>
>>Some things to watch for...
>>1.  Passing large structures or classes by value.  This can be trivial or
>>impossible to fix, depending on what you are doing with the object
>>2.  Any nested loop in a time path critical function.  Can you precompute?  Is
>>the nested loop really necessary for every call?  Can you do a table lookup or
>>some other alternative?
>>3.  Big data tables that are auto in frequently called functions (they will
>>initialize every time unless you make them static.)  If you do not change the
>>data in them, declare them as static const and they won't load over and over.
>>
>
>I'm not sure i understand what you mean by #3. I do have some date tables
>piece/sq that are used in eval (called very freq.) but they are not static as I
>change the values in them over the course of the game. I precompute them at root
>of the search and then use at the leaves.
>
>what do you mean by "data tables that are auto"?


int foo(void)
{
int stupidly_large_auto_partly_initialized[1000000] = {1,2,3,4,5};
}

if integers are 4 bytes long, then there are 4MB moved into the array at each
function call {assuming your stack does not pop a gasket}.  However, if you
modify the array, making it static will cause problems when you want to
multithread, so you can only change it to static sometimes.  If you never change
it then static const is the best.

>>But before you do anything else, profile it and find out where your time is
>>going.
>>
>>Typically, you will see 80% of the time eaten by 10% of the code.  That is where
>>to look for speedups.
>
>As of last summer my SEE routine was the biggest problem, eating 20% of CPU
>time. I know it can be optimized further, I used a recursive approach . I look a
>look at the code in Crafty but was having trouble understanding parts of it and
>I don't like to use an idea unless i get it. and copying code is of course right
>out!
>
>
>Eric



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.