Author: Dann Corbit
Date: 10:38:22 01/07/05
Go up one level in this thread
On January 07, 2005 at 13:24:47, Dann Corbit wrote: >On January 07, 2005 at 05:39:13, Uri Blass wrote: > >>On January 07, 2005 at 05:35:40, Uri Blass wrote: >> >>>On January 06, 2005 at 19:53:58, Dann Corbit wrote: >>> >>>>On January 06, 2005 at 19:15:58, Pallav Nawani wrote: >>>> >>>>>On January 06, 2005 at 18:18:40, David B Weller wrote: >>>>> >>>>>>Hi Geoff, >>>>>> >>>>>>The fact that you stumble over my code is probably a credit to your >>>>>>intellegence, and if I tried to explain: attack_mask[][], I would embarass >>>>>>myself. >>>>>> >>>>>>In fact, while thinking over how to best answer your question, I too became >>>>>>somewhat puzzled as to how what I did, actually improves GES performance. It >>>>>>really is inacurate. >>>>>> >>>>>>The part I added is at the end of control.cpp and 1 line in evaluate.cpp : >>>>>> >>>>>>s += count_ctrl() * 3; >>>>>> >>>>>> the '3' is pulled from memory - I think Prof Hyatt used it for Bishop mobility, >>>>>>but since what I am counting isnt the same, it is probably way off. WAY off. >>>>>> >>>>>>The basic idea of count_ctrl() is to detirmine who 'owns' each of the 64 >>>>>>squares. But it is very simple and naive. It makes assumptions which are >>>>>>probably true more often than not, but still wrong much of the time. eg., if >>>>>>white has a pawn attacking a square, but black doesnt have a pawn attacking that >>>>>>square - white owns the square. regardless of what else is attacking it. If both >>>>>>have pawns attacking [or, niether do] then the same idea is applied for knights. >>>>>>Then Bishops, then Rooks, then Queens. >>>>> >>>>>So what you are evaluating is board control. I had no idea it was that useful. >>>>>Maybe I will try implementing that (after I have implemented attack tables, that >>>>>is). >>>> >>>>A bitboard program will have a stupendous advantage here [considering again >>>>Fabian's code]. >>>> >>>>If you look at the eval function (where he calculates mobility) with a bitboard >>>>program you can precompute EVERYTHING and every single nested loop goes away. >>>> >>>>By a stupendous margin, all of his program's time is bottled up by eval(). >>>> >>>>If Fabian's program were converted to bitboard, it could run 5x faster. How's >>>>that for a scary thought? >>> >>>Does Fruit use more than 80% of it's time for mobility evaluation. >>>If it is not the case then I do not see where the 5x faster comes from. >>> >>>Even if it can calculate fruit's mobility evaluation 5 times faster it does not >>>mean that the program will be 5 times faster. > >Maybe not. It's a guess. There is one other slow function as well that would have to be addressed besides eval (add_captures_unroll() is the other). Those two functions are clearly the bottleneck for the program's execution. They are dominatingly slower than any other function call set. eval_piece is 20% add_captures_unroll is 8% nothing else is more than 4% If you can make those two functions even with the others you will get a lot more than 24% because flow analysis indicates that they are the bottlenecks (the Intel profiler puts a big, fat, red line on that path). My 5x was assuming that eval_piece was a gate for everything else and that add_captures_unroll could be brought under control also. Probably 5x is too much, because something else will rise up. But it would be very significant, whatever it is. >>I can also add that the question is also if fabian will not have slower move >>generator thanks to bitboards or he will be slower in other things. >> >>Fruit seems to be better than Crafty so it probably does something better. > >I am guessing that search is better, since branching factor is about 2. >I think also that his evaluation is different than that of many others so that >it sees opportunities that others miss. It happens the other way around too.
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.