Author: Eric Oldre
Date: 16:40:26 01/13/05
Go up one level in this thread
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? >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"? >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.