Author: Pallav Nawani
Date: 18:29:59 02/15/05
Go up one level in this thread
HI charles, Many thanks for your comments and for profiling the code for me. Yes, SD indeed is the suggested max depth in my engine. But on the other hand, I will compare a debug version (No problems with debug versions) against a optimized version, just in case. Best regards, Pallav On February 15, 2005 at 18:27:35, Charles Roberson wrote: > > I had to fix a line of code to get it to compile, then I had to turn off > all the debug statments to get a reasonable profile. But, it profiled without > a problem for me. > > Also, I get several "will never be executed" warning messages. Maybe you > should look at them. > > Since you lack a benchmark routine and your perft doesn't call > the eval function, I set up a new board and set search depth to 11 ply. Then > typed e2e4. > > Here are the big hitters for debug version: > % time routine > 43.91 simple_pos_eval > 18.83 gen_captures > 9.33 isattacked > 5.12 make_move > 4.76 order_search > 4.5 search > 4.03 get_next_move > 3.10 gen_moves > 1.44 undo_moves > > Here are the big hitters for the O2 version: > % time routine > 41.07 simple_pos_eval > 16.65 gen_captures > 7.23 search > 6.77 isattacked > 6.64 ordered_search > 5.88 make_move > 4.33 gen_next_move > 2.40 gen_moves > 2.10 qsearch > 1.77 undo_move > > Eventhough I told it sd 11 and made the same move in both runs, the > number of calls to each routine were drastically different between the > debug profile and the optimized profile. If you can't answer why then > you should. If sd is a suggested depth as opposed to a fixed depth > then I understand. From your help lines it looks like it is a suggested > depth. I would suggest putting in a fixed depth so that the call counts > for each routine come out the same no matter the level of optimization. > At that time, if they come out different -> you have bugs. > > Looks like your work is cut out for you if you want a 2x speedup. > Amdahl's law says you are going to need to work on several of the > routines or fine some tricks that are core to several of them. > Speeding up the pos eval can only take 44% off the run time with > infinite speedup. From the looks of your data structures you could > be spending a lot of time falling out of registers to cache. Remember > Crafty is a bitboard program thus many of its operations stay in the > registers which are faster than cache. > > If you make your piece eval into functions and get rid of the goto's > you could see better where the problem is. A quick glance shows you > use int where a char or short will do. Also, some ptr arithmetic may > help. There are several boolean tricks you could use such as: > if ((x+y)>0) could be if (x|y) > now this assumes that both x and y can never be negative. > > Wow, I meant for this to be short and sweet. I apologize for getting > carried away. > > Charles
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.