[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [gnugo-devel] influence speed exactness tradeoff
From: |
Arend Bayer |
Subject: |
Re: [gnugo-devel] influence speed exactness tradeoff |
Date: |
Wed, 26 Jun 2002 23:03:17 +0200 (CEST) |
On Wed, 26 Jun 2002, Gunnar Farneback wrote:
> We have made similar tradeoffs before, e.g. setting the fourlib_depth
> to 0 during make_domains(). In my experience these have often caused a
> fair amount of trouble, especially when inaccurate results have
> poisoned the caches.
This one has the advantage, of course, that it does not lead to
incorrect cache lookups, as the remaining_depth is stored there.
> > I will probably also try out two more exactness-speed tradeoffs, to make
> > owl and influence reading calls less expensive:
> > * disable all (including legal) ko captures (as all the helper
> > functions do not even test for ko results, this seems a reasonable
> > thing to do).
>
> I'm doubtful about this and also about the premise. Although there are
> no explicit tests for KO_A and KO_B in the constraints, there's an
> important distinction between "== WIN" and "!= 0".
Hmm. Is that distinction really that big? Of course, disallowing all
illegal ko captures (which saves about 10% of reading nodes) is the same
as changing "== WIN" to ">= KO_A".
Anyway, in both cases, "== WIN" and "!= 0", you could still disallow all
ko captures for one side from the very beginning. Double kos aside (and I
doubt we should worry about double kos in an owl pattern helper), you
can't get WIN with any line that includes a (legal or not) ko capture.
> > * disable passes
>
> Can you explain what you mean here? It's vital that the defender is
> allowed to pass in certain seki positions or where the only local
> moves are to fill in one of two one-space eyes.
It is also expensive. I once tried it out and manually disabled all passes,
and it reduced the number of reading nodes by ~20% (I didn't check whether
this was caused by changes in the owl computations though, as far as I can
remember).
Once we use Trevor's matchpat_goal_anchor for owl pattern matching (this
is still somewhere on my personal to do list...), a _vast_ majority of the
time used for owl computations will be spent in the reading code. My
general impression a that we should guess a little more often so that we
can compute more owl nodes per second. Of course, I have nothing to back
up this opinion.
I missed that case with two one-point eyes though, I had only thought
about sekis. So I'd guess this it is not acceptable at all to disallow
passes when testing owl_safe_move. For the owl pattern helpers, I still
think it might be worth trying out.
Another thing one could try is finding some heuristics in reading.c
deciding when we don't need to try the pass move.
Arend