Author: Robert Hyatt
Date: 07:50:07 08/17/05
Go up one level in this thread
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... > >> >> >>> >>>>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.