Author: Dann Corbit
Date: 14:30:53 03/05/04
Go up one level in this thread
On March 05, 2004 at 17:09:43, Uri Blass wrote: >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. But if the second move in the move list also fails high? And the 3rd? And the 5th? And the 13th? That would be very bad. >>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. I think you are right that he only used it for repetition, now that I think back on it.
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.