The file ³batch² explicitly sets to 2, but I noticed that not all your scripts concatenate the ³batch² file. Bench.sh does, bench2.sh does, bench3 doesn¹t, and bench4-.sh (and subfile bech4-sub). Maybe I am tired at this hour and am missing it as well. It seems like some are 0 ply and some are 2 ply?
On 11/09/09 1:01 AM, "Ingo Macherius" <[email protected]> wrote: > 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 I¹ll 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. >> >> I¹m runnign some 4 ply cache tests ovr the next 24 hours. I¹ll 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
