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