gnugo-devel
[Top][All Lists]
Advanced

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

Re: [gnugo-devel] paul_3_13.5.gz


From: Arend Bayer
Subject: Re: [gnugo-devel] paul_3_13.5.gz
Date: Fri, 6 Dec 2002 08:42:04 +0100 (CET)

Paul wrote:

> i wrote:
> > > the patch cuts off around 600k (!) from the executable and must give a
> > > measureable speedup as well (haven't checked).
> >
> > today i checked the speed and got an unexpected result: the 1D
> > version is a tiny little bit slower than the 2D one - the
> > difference is 1 - 2 seconds on nngs.tst (which runs for a bit
> > more than 20 minutes on my computer). i did the check three
> > times and the results are very consistent.
> >
> > either something went wrong or the rather large transformation[][]
> > array (almost 43k) is not doing very fast. i'm going to look
> > through the whole patch in search for a mistake. i'll post the
> > results soon.

Well, it sounds very plausible that a lookup in a 43k array will be
significantly slower than doing a matrix multiplication by hand.

Memory latency is really slow, compared to fast processors today.
(I even wonder whether the DFA matching is still faster, at all, on
2GHz+ processors.)

> - scan_for_patterns() is called _very_ often, so
>
>     dfa_pos = DFA_POS(I(anchor), J(anchor)) + DFA_OFFSET;
>
>   can be sped up with a lookup array, like
>
>     dfa_pos = lookup_dfa_pos[anchor];

I am not sure this will be a speedup, for the same reason.

> - looks like `p' array is really not needed with the patch. not
>   that copying board to p takes any noticeable time, but accessing
>   board[] instead of p[] can also improve caching.

Hmm, it looks to me that it is not necessary for DFA matching at all.

Arend







reply via email to

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