Author: Uri Blass
Date: 14:09:43 03/05/04
Go up one level in this thread
On March 05, 2004 at 16:37:16, Dann Corbit wrote: >On March 05, 2004 at 16:05:37, Uri Blass wrote: > >>On March 05, 2004 at 14:18:24, Dann Corbit wrote: >> >>>On March 05, 2004 at 09:12:39, Mathieu Pagé wrote: >>> >>>>On March 04, 2004 at 15:25:53, Dann Corbit wrote: >>>> >>>>>On March 04, 2004 at 15:16:43, Mathieu Pagé wrote: >>>>> >>>>>>Hi, >>>>>> >>>>>>I've just change my minimax algorithm for an AB one. (Yes I know i should have >>>>>>done this long long time ago, but i did want to keep it simple until it could >>>>>>play a complete game and understand _all_ the chess rules). >>>>>> >>>>>>As expected my engines can search deeper (3-4 more plys) than the old version in >>>>>>the same time, but the NPS drop dramatically, going from 3.6M nodes/s to a >>>>>>little bit over 2M nodes/s. It's about 44 % decrease. >>>>>> >>>>>>I think it is normal that the nps of Minimax was greater then AB's one because >>>>>>in AB lot of move are generated, but not searched (so they are not add to the >>>>>>number of nodes) >>>>>> >>>>>>but i think that going from 3.6M to 2M is a big difference. >>>>>> >>>>>>Is this behavior normal or did I put an unusual overhead in my algorithm (For >>>>>>now, i have carefully revised my code and can not see what it is) ? >>>>>> >>>>>>TIA :) >>>>>> >>>>>>Mathieu Pagé >>>>> >>>>>How do you count nodes? >>>> >>>>Each call to AB, I count it as a node. (I have no quiescence or other fancy >>>>things) >>> >>>Then I would expect what you are seeing. >>> >>>>>Does your perft calculation give a different rate now? >>>> >>>>No, my perft is as fast as it was (over 4 millions nodes per seconds) >>> >>>I would not worry about it then. >>> >>>>>I suspect the difference is that you spend more time in the search and less time >>>>>in the move generator. But that is only a guess. >>>> >>>>I guess you mean more time in the move generation less in the search. did you ? >>> >>>No. If you spent more time in the move generator, you would be closer to the 4 >>>million NPS. You spend more time in the search and call the move generator less >>>often. That is generally a good thing. You will see the same thing when you >>>strengthen your evaluation, because it will spend more time in eval and less in >>>move generation. For an experiment, strap on an evaluation that does nothing >>>but count wood. Probably, you will see something very high in NPS like one >>>million and stupendous depth. But it will play like crap. >>> >>>>Note that i still have no ordering except a primitive LVA (without MVV ??) move >>>>ordering is the next step on my TODO >>> >>>Hash next. The most important thing for move ordering is hashing, by far. >> >>I do not think that it is the most important thing for move ordering. >> >>I guess that you get more speed by good captures first and history tables and >>not by hash after you already have the basic things. >> >>I do not know about hash when you have nothing but there are many positions that >>are not in the hash tables so I do not think that hash alone can be more >>productive than what tscp does > >The most important thing for alpha-beta move ordering is to search the best node >first. No It is only important to search move that is good enough to produce fail high first. > >The most dominant thing for move ordering is to select the pv nodes. > >The PV nodes are stored in the hash table. You can do it without a hash table, >but it is a lot less efficient. I never searched without pv array so I admit that I do not know the importance of it because I did not compare searching without pv array to searching with pv array. When I think about now I think that it is better to start with hash because you may save the time of special code to start with the pv line by first saving it in the hash like crafty. The current version of TSCP uses hashing >specifically to do move ordering. > >You are probably thinking about an older version of TSCP, because hashing is new >with 1.8x. I thought about 1.73 but as far as I know the only difference between 1.8x and 1.73 is having book and hash code that is not used for order of moves but to aboid drawing by repetition in won positions. I did not read about significant improvement in tscp from 1.73 to 1.8x and I am sure that with using hash for order of moves Tom could do a significant improvement. Uri
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.