Re: [gnugo-devel] FW: Owl tuning help needed

[Arend Bayer]

> Hi,
>
> As I recently noticed how bad the A1120 pattern is, I came up with an idea
> this afternoon and tried following change :
>
> Pattern A1120
(...)
> The idea is simply to make this pattern do what it was primarily meant for,
> i.e. "block escape" and nothing more.

> As expected, I got a quite big delta : 18 PASSes and 25 FAILs (I won't enter
> in the details here, see why below). And at the same time, I observed this :
> (btw, out of curiosity, why isn't there statistics in all .tst files ?)
>
>                    delta owl nodes
> ----------------------------------
> total             -267408  -18.19%
>
> If you turn things upside down, this means the current engine is using 260
> K-nodes for 25 PASSes and 18 FAILs...

This huge delta convinces me that we need to automatically watch for
performance regressions in the same way as we are already watching for
move choice regressions. (Just counting difference in owl nodes for
owl.tst just doesn't suffice, e.g. Also your numbers show so much
variation that any single test suite is not enough.)

The way I'd suggest to do this: Create a new symbol for regress.awk,
e.g. as follows:

# Report number of nodes visited by the tactical reading
10000 get_reading_node_counter
#? [54321]!

regress.awk would then report:
10000: old value '54321', new value '65432'.

(Or maybe s.th. fancier like computing the relative difference in %,
if someone knows awk better than me. And maybe even compute the total
number of trymove/reading/owl nodes.).

The expected number could be automatically updated by breakage2tst.py,
of course, otherwise this would be a hassle.

Opinions? Awk experts anywhere?

> I think the performance gain is worth working some more on this patch. When
> I made the change, I knew that the engine would probably miss some pattern(s),
> about peeps and/or tower poking for instance. I think the point is to create
> 'good' ones, what can prove somewhat difficult. Also, all these fails must
> be checked one by one...
I agree and agree with Gunnar, that many patterns are simply to general.

> So, would anybody be interested in a collaborative work on this stuff ?
Generally yes, but at the moment there is still some other stuff to
do... It would definitely be useful to start collecting a list of such
potentially useful changes.

Arend