On 29-okt-08, at 16:24, Don Dailey wrote:
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.
I also believe it's a win. But I agree you can't discount the
possibility of something changing in CPU behaviour in such a way that
what used to be ineffficient before now becomes more efficient.
In this case I believe that hiding the implementation of the
'marking' in a little class is exactly the right thing to do. That
way I can easily replace the implementation with one that clears the
array instead of increasing the marker. And I'll only have to make
changes in one place instead of dozens, or more. Not that I had this
in mind when I designed it, it's just the beneficial side-effect of
OO design in general.
Just now I had a little experiment where I added some code and all of
a sudden my program became 10% faster. CPU's are definitely not as
predictable as they used to be. But overall I find I do best in
writing efficient code when I code towards the theoretically most
efficient algorithm, and not towards some processor quirk. But I'm
sure it's also very much a matter of taste and style.
Mark
_______________________________________________
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
