Re: speedups (was: Re: [gnugo-devel] Timing data)

[Gunnar Farneback]

Arend wrote:
> 1. Owl patterns should have a classification that can tell
>    "constraint is quick to evaluate". In this case, the constraint should
>    be evaluated before owl_safe_move is called. Consider e.g. VA24:
>    
> Pattern VA24
> # gf New pattern. (3.1.14)
> 
> X*           capture inside eyespace, not ko
> 
> :-,-,value(76)
>   
> A*
> 
> ;lib(A)==1 && owl_eyespace(*,A) && olib(*) > 0
> 
>    which gets matched geometrically quite often.
> 
>    Maybe I'll do that today, it's only 5 lines of code plus selecting the
>    patterns.

This may be a good idea, but hand selection of the patterns doesn't
sound very maintainable in the long run. I suggest the following
generalization:

* Introduce a new constraint_complexity field in the pattern struct.
* Associate a cost with each autohelper in the big table in mkpat.c.
* Compute the constraint complexity in mkpat by summing the cost for
  each of the involved autohelpers.
* Use the constraint complexity estimate to decide whether to evaluate
  constraint or safe move condition first.
* The constraint complexity estimate could also be used when sorting
  the evaluation order of owl patterns with the same value.

This solution would be more generally useful, automatically apply to
new patterns, and be easy to tune just by changing table values.

> 2. I think pop_owl would be basically unnecessary if the owl_data is
>    directly written to and read from the stack. That'd save 3%. (I haven't
>    really checked whether this would work.)

The very reason why push_owl() and pop_owl() exist in the first place
is that the owl data is big enough that storing it on the stack caused
stack overflow on some platforms.

/Gunnar