I want to add that the most efficient thing for modern processors isn't necessarily the most efficient theoretical algorithm. Years ago for instance hash tables were "more efficient" than they are today, but now perhaps B-Tree's win for similar purposes because they are designed to be cache friendly. In theory hash tables are as fast as you can get.
In this case, I believe the aging algorithm is a win - but you are just seeing some random side-effect. If you re-arrange the code it may suddenly be slightly faster, or even slower. - Don On Wed, 2008-10-29 at 14:13 -0400, Don Dailey wrote: > On Wed, 2008-10-29 at 13:49 -0400, Michael Williams wrote: > > I am unable to explain the results. > > > It's just noise. Any code change can slightly help or hurt for no > easily explainable reason. It could be some effect on caching, the > optimizer, branch prediction, or something else. You do have a more > complicated test now, based on a variable instead of a constant. It's > hard to imagine that outweighs the cost of initializing an array > however, although I think this kind of thing is really fast in modern > processors (almost no branch mis-predictions, full pipe-lining, etc.) > > And this is the kind of change that even in a perfect world isn't going > to have noticeable impact anyway. So if anything else changes it could > actually slightly hurt. Even if it showed a slight speedup you could > not for sure attribute this to the more efficient algorithm. > > > - Don > > > _______________________________________________ > computer-go mailing list > computer-go@computer-go.org > http://www.computer-go.org/mailman/listinfo/computer-go/
signature.asc
Description: This is a digitally signed message part
_______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
