Author: Tony Werten
Date: 22:40:24 08/17/05
Go up one level in this thread
On August 17, 2005 at 10:50:07, Robert Hyatt wrote: >On August 17, 2005 at 01:57:38, Tony Werten wrote: > >>On August 16, 2005 at 18:17:16, Robert Hyatt wrote: >> >>>On August 16, 2005 at 18:09:40, Dann Corbit wrote: >>> >>>>On August 16, 2005 at 17:46:10, Robert Hyatt wrote: >>>> >>>>>On August 16, 2005 at 17:37:30, Uri Blass wrote: >>>>> >>>>>>On August 16, 2005 at 17:30:02, Paolo Casaschi wrote: >>>>>> >>>>>>>On August 16, 2005 at 17:26:28, Dann Corbit wrote: >>>>>>> >>>>>>>>On August 16, 2005 at 17:16:33, Paolo Casaschi wrote: >>>>>>>> >>>>>>>>>>I know that usually when program improve they improve in all time controls. >>>>>>>>>>I do not know of evaluation changes or search changes that make programs weaker >>>>>>>>>>at blitz but stronger at long time control. >>>>>>>>>> >>>>>>>>>>In thoery it can happen but I need to see a proof for it and I believe that >>>>>>>>>>fabien mainly test in blitz time control(he can correct me if I am wrong) >>>>>>>>>>because usually productive changes in blitz of adding knowledge to the >>>>>>>>>>evaluation are also productive at long time control. >>>>>>>>> >>>>>>>>>Do you have any proof or evidence that there is some correlation between blitz >>>>>>>>>strenght and slower speed strenght? >>>>>>>>>If you dont, then we can only compare assumptions and I tend to agree with Bob >>>>>>>>>Hyatt since the same non-correlation is evident with humans and because common >>>>>>>>>sense... >>>>>>>> >>>>>>>>There is definitely a general correlation between strength at blitz and strength >>>>>>>>at standard time control. However, there are also exceptions to the rule. >>>>>>>> >>>>>>>>For instance, we will expect Fruit to be stronger than Golem at blitz, in the >>>>>>>>same way that we would expect Kasparov to clobber me at blitz. >>>>>>>> >>>>>>>>On the other hand, Mike Valvo overperforms at blitz, and Amy used to >>>>>>>>underperform badly (it was mostly due to bad algorithms for time management at >>>>>>>>fast time control). >>>>>>> >>>>>>>Exactly my point. >>>>>>>There is some correlation but there are exceptions and it's possible that >>>>>>>different players have a different type of correlation, thus the point of Bob >>>>>>>Hyatt stands. >>>>>>> >>>>>>>--Paolo >>>>>> >>>>>>I still need to see an example for programs without significant bugs that show >>>>>>significant difference(Amy is not a good example because of bad time management) >>>>>> >>>>>>There may be cases when A is 50 elo weaker at blitz and 50 elo better at long >>>>>>time control but I doubt if you can find cases when A is 100 elo weaker at blitz >>>>>>and 100 elo stronger at long time control. >>>>>> >>>>>>Uri >>>>> >>>>> >>>>>I'm not going to waste all day here, but a parallel search program can play >>>>>worse in endgames than in the middlegame, if sufficient care is not taken. >>>>>Would you really want to sic 8 cpus on a position which on average only has 4 >>>>>moves or less? Overhead goes thru the roof. >>>> >>>>It seems that 4 threads could work on the root node, and 4 threads on the next >>>>elements of the pv as one possibility. Probably a gross oversimplification, of >>>>course. >>> >>>Yes it is. I need to know the "alpha" value for the root before I sic 4 >>>processors to work there else overhead goes up (the young-brothers wait type >>>approach)... :) >> >>Actually, you don't :) >> >>If the alternative is no splits at all, one might just let the processors search >>with their own alpha beta window for each move. >> >>Tony > >The problem is that you then get no speedup at all there. Just look at how long >it takes to search the first move at the root, compared to searching all the >others in a tiny fraction of that time... Maybe, but I can imagine it does. First, I would guess that the information in the hashtable is better, so that could give improvements. Second, in case of a change in best move, you already have a exact "second best" score. Most likely it is worse than normal splitting, but I think it will be better than no splitting. Then again, making the splitlevel "minimal depth remaining" variable compared to total time is probably easier and better. (is that a sentence ?) Tony > > >> >>> >>> >>>> >>>>>Same thing happens in blitz. Trees are a fraction of their normal size. To >>>>>split them invites excessive search overhead. In extreme cases (I have seen >>>>>this in Crafty) I get to do _zero_ splits in a blitz game (this happened in a >>>>>couple of the games Peter played today in fact) which means the search is >>>>>running about 1/6 its normal performance level. Think a factor of 6 slower will >>>>>make a measurable difference in speed vs normal chess? Easily. over-compensate >>>>>for that and you greatly slow the search down by having excessive split >>>>>overhead. And screwing up on this side of the equation can make the parallel >>>>>search _slower_ than a single-processor search, which can totally wreck >>>>>performance... >>>>> >>>>>Enough of this for the moment. The problem is real...
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.