[Top][All Lists]

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

Re: [Bug-gnubg] Building gnubg on windows - A newbies voyage

From: Jon Kinsey
Subject: Re: [Bug-gnubg] Building gnubg on windows - A newbies voyage
Date: Mon, 07 Feb 2005 10:44:17 +0000
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041206 Thunderbird/1.0 Mnenhy/0.7

macherius wrote:

Did so, the results speak for themselves. The binaries tested were built
with all P4 whistles and bells enabled using the Intel 8.1 C Compiler. The
machine is a 865PE based Pentium 4C.

Gnubg-GUI-P4-NoHack-GTK261               : 21800 eval/s
Gnubg-GUI-P4-fXHack-GTK261               : 31500 eval/s
Gnubg-NOGUI-P4-NoHack-GTK261             : 27900 eval/s
Gnubg-GUI-386-StandardDistribution-GTK13 : 21400 eval/s

I also had the regular distribution binary and a P4 bolide both eval the
same 7pt game with 400+ moves in 2ply/prune, and it ended 7:30 min vs 8:20
min in favor of the standard distribution. That was without the fX hack,
which however should not be relevant for real crunching.

I can imagine two things to be the reason of that:

1. SSE2
SSE2 instructions fly if you manage to feed the floating point pipeline
steadily. Whenever you subroutine for any reason, the cache and the pipe
break and the speed gain is lost.

2. GTK 2.6
Whatever the event models of 1.3 and 2.6 are, GTK 2.6 clearly is slower
here. However, in general it appears to be faster (i.e. startup times etc.)
to me. So what options exist to remove GTK-Hooks from the actual evaluation
loops? It would be a shame to give 2.6 up because of this.

I had a quick look on Friday, and started getting 2.6 to build here
(with mingw).  The speed seemed ok.  I'll try and get it all working today.

I like the idea of using a separate thread to do the evaluations - this
would remove the cludgy polling that goes on now.  I imagine it would
cause all sorts of other build/run problems though.

A simpler solution may be to just increase the time between polls as it
currently checks each 256 evals and with more than 20,000/sec this means
the ui is getting checked up to 100 times a second, where I guess only
once or twice a second (and/or when things change) might be fine.


Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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