On Fri, Nov 20, 2009 at 10:31:21AM +0100, Petr Baudis wrote:
> For the liberties, of course that applies since they are used very often
> and take little memory (if you are sensible about it), but also always
> get in mind to avoid universal truths - not all features pay off to be
> maintained incrementally. E.g. for my heavy playouts, I tried to
> incrementally update features (mainly is-a-self-atari), but it turned
> out the cache hits for all the stored information _and_ the work
> involved in finding out what parts of the board I actually need to
> recompute noticeably outweighted the benefit. Maybe if I optimized it
> further, I would reduce the costs, but hardly much below the current
> costs of re-computing the features around the play condidate on each
> move.
For sure, there is no universal truth, but my point here that
recomputing some features have a hard additional cost.
For drawing play random from weighted points you have to keep these
weights and additional data-structure, in my case an array with sum of
line's weights and the total sum of weights.
If you need to recompute some features each time you have to draw a
play, you have to update these data each time and next to restore them
and this can also be very costly.
In effect, there is some features where this cost is still inferior to
the cost of maintaining them incrementaly, but for thoses I prefer to
fall back to approximations that can be easily computed incrementaly.
All of this really depend on the design of the engine I think, and I
have to ponder a bit what I have said. It's probaly something more like:
try to reduce to the minimum what you recompute each time in favor on
computing it incrementaly because it's generaly more cheaper, but make
some test ;-)
For the cache point, the proble here is it's very hardware specific. My
goban even with all fancy removed, never fit in a few L1 cache line, so
in all case it will be in L2, and there is enought room there for me
even on my old computer. As profiled, the prefetching done by the
processor seems to work well in my case and for the moment there is no
big problems here, but my big fear is that a small change in the engine
can always make this fall by introducing a pattern badly handle by the
processor... and another processor with small difference can badly
handle the current situation, so I take all cache informations with
care.
Tom
--
Thomas Lavergne "Entia non sunt multiplicanda praeter
necessitatem." (Guillaume d'Ockham)
thomas.laver...@reveurs.org http://oniros.org
_______________________________________________
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
