Hello!

I am writing a (simple) chess program and I think it is rather slow,
i.e. it would not search very deep (only a few plies) in a short
period of time. I thought one reason might be a poor move ordering (I
use alpha-beta with iterativ deepening).
So I read some posts in this group to get informations how to make it
faster.
Robert Hyatt suggested to test the move order quality by computing a
number that divides all cutoffs happening at the first move at a
certain node by all occuring cutoffs. If that number was about 0.9 it
would be good.
Well - I get 0.9 most of the time (hoping that I compute the number
right).
On the other hand I tried the following:
In my evaluation function I did the usual computions, but instead
returning
the computed value I always returned 0. This - I thought - would give
perfect cutoff scenarios, while everything else of the algorithmus
would not be affected (as opposed to directly returning 0, which is of
course additionally faster as _no_ evaluation is done at the nodes).
However, comparing the usual response time (with seemingly good move
ordering) to the one obtained when eventually returning 0, the latter
one was _much, much_ faster, especially when searching deeper!

So I am confused now. It would be great, if anyone could help me.
Thanks in advance,

-delphi-

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Delphi wrote:

On the other hand I tried the following:
In my evaluation function I did the usual computions, but instead
returning
the computed value I always returned 0.

... comparing the usual response time (with seemingly good move
ordering) to the one obtained when eventually returning 0, the latter
one was _much, much_ faster

Random thought - does your compiler avoid generating code for stuff that
is never used? Thus returning zero might optimise out some or all of
your evaluation computations.

Sometimes these computers are too damn clever.
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE/Pl/kGFXfHI9FVgYRAmGHAJ9lhNvs7275vUm4ZahwcSaLN3iImQCgg gb1
ASy1wSSSR+NPLGsud/Dn3JM=
=eIV1
-----END PGP SIGNATURE-----

Simon Waters wrote in message ...
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Delphi wrote:

On the other hand I tried the following:
In my evaluation function I did the usual computions, but instead
returning
the computed value I always returned 0.

... comparing the usual response time (with seemingly good move
ordering) to the one obtained when eventually returning 0, the latter
one was _much, much_ faster

Random thought - does your compiler avoid generating code for stuff that
is never used? Thus returning zero might optimise out some or all of
your evaluation computations.

Sometimes these computers are too damn clever.
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE/Pl/kGFXfHI9FVgYRAmGHAJ9lhNvs7275vUm4ZahwcSaLN3iImQCgg gb1
ASy1wSSSR+NPLGsud/Dn3JM=
=eIV1
-----END PGP SIGNATURE-----


Oh - I did not think of something like that!
Anyway, I changed the value 0 to a computation that yields also a
constant value but only if a certain condition is fulfilled (which is
true in the first moves), so I think this could not be optimized. The
result is the same:
approx. 10 times faster response than without a constant value, while
immediately returning 0 is yet faster (which also means, that it can't
be a compiler optimization issue (is vc6++, by the way).

thanks anyway,
-delphi-

Am 16 Aug 2003 14:41:34 -0700 hat (Delphi) geschrieben:
Simon Waters wrote in message news:bhlmhr$2hq$1$8300dec7
@news.demon.co.uk...
[...]
Random thought - does your compiler avoid generating code for stuff that
is never used? Thus returning zero might optimise out some or all of
your evaluation computations.
[...]
Oh - I did not think of something like that!
Anyway, I changed the value 0 to a computation that yields also a
constant value but only if a certain condition is fulfilled (which is
true in the first moves), so I think this could not be optimized.
[...]

If you want to be sure about that, make certain that your evaluation
routine produces a side effect, e.g., by adding its result to a
(global) dummy variable. After that, you can return what you want,
the compiler won't skip the preceding code.

Regards

scardanelli wrote in message ...
Am 16 Aug 2003 14:41:34 -0700 hat (Delphi) geschrieben:
Simon Waters wrote in message news:bhlmhr$2hq$1$8300dec7
@news.demon.co.uk...
[...]
Random thought - does your compiler avoid generating code for stuff that
is never used? Thus returning zero might optimise out some or all of
your evaluation computations.
[...]
Oh - I did not think of something like that!
Anyway, I changed the value 0 to a computation that yields also a
constant value but only if a certain condition is fulfilled (which is
true in the first moves), so I think this could not be optimized.
[...]

If you want to be sure about that, make certain that your evaluation
routine produces a side effect, e.g., by adding its result to a
(global) dummy variable. After that, you can return what you want,
the compiler won't skip the preceding code.

Regards

Tried it, same result as before. So I am still confused...
-delphi-