gnugo-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gnugo-devel] engine/influence.c (and DFA)


From: Heikki Levanto
Subject: Re: [gnugo-devel] engine/influence.c (and DFA)
Date: Tue, 3 Sep 2002 21:21:27 +0200
User-agent: Mutt/1.4i

On Tue, Sep 03, 2002 at 08:11:54PM +0200, Marco Scheurer wrote:
> 
> influence.c still has bidimensional arrays, I think, and even with the 
> 1D transition you still have a multiplication, don't you? 

In principle yes, but not necessarily in practice - going from (x,y) to
(x+1,y) in 1-D is not going from s*x+y to s*(x+1)+y. It is more like going
from s*x+y to s*x+y+w, or from p to p+w. In short, you do not need this
multiplation on every iteration of the loop.

> >Also, isn't chasing pointers supposed to be the worst possible you
> >can do the the cache? (I.e., most likely to result in cache misses.)
> Yes, this could be an issue, and it probably depends, again, on 
> architectures and compilers.

Again, we are not "chasing pointers" as in linked lists, but doing just one
more indirection. With modern cache sizes both pointers and what they point
to are likely to be in the cache already.

> This makes me think that all these optimizations (loop unrolling,
> inlining, etc) should probably be left out.

Agreed! If it was not for readability, I would recommend leaving the
unoptimized pieces in behind some #defines, so that we could compare what
happens. But since readability is important - especially so in a communal
project with many contributors and complex code - I vote for dropping any
optmization that can not be shown to give at least 5% speedup in a whole
game! Even those that can, I would vote for seeing the plain algorithm coded
first, proven to work, and then (if at all) optimized.



Humbly

        Heikki


-- 
Heikki Levanto  LSD - Levanto Software Development   <address@hidden>





reply via email to

[Prev in Thread] Current Thread [Next in Thread]