Author: Mikael Bäckman
Date: 04:03:55 05/07/04
Go up one level in this thread
On May 07, 2004 at 04:30:09, Vincent Diepeveen wrote: >On May 06, 2004 at 12:45:43, Robert Hyatt wrote: > >Bob let's get realistic. > >BK is a flawed testset to test parallel speedups at. Why? I know nothing of parallel processing, but what in the BK makes it bad for parallel testing? /Mikael > >What happened is. You took 4 positions from that to 'proof' your 3.1. > >That gets disproven then by GCP doing statistical math where you know really >less than a waterbird from. You do not even realize what the +- behind every >measured speedup means. In fact you never provide them yourself. > >GCP then is doing different tests at your quads and very clearly determines 2.8 >using a-symmetric king safety. > >My 1.0 out of 2 speedup for crafty came of course from using tests with >symmetric king safety. > >But GCP using 30 positions gets down to 2.8 speedup. > >And he gets one time 3.2 and another time 3.0 for speedup when searching >fullwidth. > >a) this shows how poor your way of representing things is. You are just showing >things like you want them to see > >b) i do not believe a crap you did a honest test where at position 21 in BK the >crafty on average gets a 2.4 speedup when searching fullwidth. No matter how i >test fullwidth at position 21, speedups are better there for fullwidth using >asymmetric king safety. > >You did not do a honest testing to get to your numbers, even in those 4 >positions and yet you deny GCP's testing at 30 positions which were honestly >done, to be true. > >This shows your true nature. > > > >>On May 06, 2004 at 12:19:13, Gian-Carlo Pascutto wrote: >> >>>I hope you don't mean the ones blow. >>> >>>Are you still claiming you 'measured' 3.1 which supposedly contradicts >>>the 2.8 I measured? >> >>I don't know what any of that refers to. My formula came from running the BK >>test (23 positions, excluding #1 an instant mate in 3). >> >>I am trying to get the disk set up and installed now that I sent to AMD for the >>last CCT event. While I had access, I ran the BK test to get the data. I had >>promised Martin that I would post the numbers. >> >>But you _really_ need a better vocabulary. I have not tried to "contradict >>2.8". I have _clearly_ said that the speedup varies and that 3.1 is the value >>suggested by a linear approximation fit to a non-linear function. >> >>I do _not_ understand the obsession with "is it 2.8 or 3.1"? It could well be >>_both_. >> >>I have _always_ called this an approximation. Let me get the log files and grep >>the times for Martin. I'll put the logs on my ftp machine since they will be >>fairly long, if you want to see the opteron data for 1-4. >> >>> >>>>Return-Path: <gcp@sjeng.org> >>>>X-XS4ALL-To: <diep@maildrop.xs4all.nl> >>>>Date: Fri, 9 Aug 2002 09:14:59 +0200 (MEST) >>>>From: Gian-Carlo Pascutto <gcp@sjeng.org> >>>>X-Sender: <giancarlo@garf.natrese.be> >>>>To: "Robert M. Hyatt" <hyatt@cis.uab.edu> >>>>Cc: <diep@xs4all.nl> >>>>Subject: Re: Parallel results so far >>>> >>>> >>>> >>>>On Thu, 8 Aug 2002, Robert M. Hyatt wrote: >>>> >>>>> Here is the results: >>>>> >>>>> ----------------------------------------------- >>>>> ---null=2/3--- ---null=off--- >>>>> position 1cpu 4cpu S/U 1cpu 4cpu S/U >>>>> kopec 21 27.9 10.7 2.6 30.3 12.4 2.4 >>>>> kopec 22 22.5 6.1 3.8 26.0 7.5 3.5 >>>>> kopec 23 33.5 11.2 3.0 20.9 6.4 3.3 >>>>> kopec 24 18.1 6.0 3.0 26.2 8.3 3.1 >>>>> >>>>> ----------------------------------------------- >>>>> note. all positions were searched for 30-45 seconds >>>>> with the last 1-cpu output used to measure how long >>>>> the 4-cpu search took to reach the same output (say >>>>> the end of a search, or a PV move and score displayed). >>>>> >>>>> Vincent claimed "I never ran this test." Thought I would >>>>> run it _again_ just to expose "baloney". >>>>> >>>>> I think the conclusion from the above is >>>> >>>>Conlusions from the above? Howso? >>>> >>>> speedup >>>>Nullmove 3.1 +- 0.25 >>>>Non-nullmove 3.1 +- 0.25 >>>> >>>>The standard errors (1SD) are way too huge to allow what >>>>you try to conclude. I measured a speedup of 2.85 with >>>>nullmove and 3.1 without, whereas your test wouldn't even >>>>be able to differentiate between the two. >>>> >>>>If you want to scientifically settle this, >>>>you'll need more and better data. >>>> >>>>(I couldn't find the CCC article reffered to earlier) >>>> >>>>-- >>>>GCP
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.