I shouldn't write mails that early in the morning. See the file "batch" for why it wasn't 0ply. 2ply was set explicitly ... Ingo
-----Original Message----- From: Michael Petch [mailto:[email protected]] Sent: Friday, September 11, 2009 8:41 AM To: Ingo Macherius; [email protected] Subject: Re: [Bug-gnubg] Benchmarks on server class machines and resultingchange requests The 0 ply might explain why your performance is marginal at around ~10% (This is a guess until I do a run on your scripts/data). But at 0 ply, each move is basically independent. Inputs get fed to the, the results come out, they get added to the cache but the likelyhood of that cache getting reused is slim. If you do 1 ply all the possible distinct rolls (21 of them) get analyzed, so generally the next move in the game is already cached from the previous data. The only thing that had me real curious on the data was how a large cache (especially now that I know it was 0 ply) has significant overhead as your charts suggest (> 2^25) except that it went out to swap space and was paging data and was more costly than going to the neural net to recalculate the numbers. I would have expected it to reach a threshold and stay there. My testing on 2 ply suggests that. Now I am using at present the code as of September 10th, so Ill also produce the data with an older CVS release similar to yours and see what I get with your data on my system, and compare it to the latest but do it on 0 ply,1ply and 2 ply. Im runnign some 4 ply cache tests ovr the next 24 hours. Ill queue up your scripts when its complete and see what happens. On 10/09/09 11:42 PM, "Ingo Macherius" <[email protected]> wrote: Ah, one missing detail: I didn't use any .gnubgrc, so all settings are whatever the defaults for a newly built binary were on August 1st 2009. Probably that means 0 ply. Ingo
_______________________________________________ Bug-gnubg mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-gnubg
