Author: Robert Hyatt
Date: 07:25:38 09/07/02
Go up one level in this thread
On September 07, 2002 at 09:50:17, Sune Fischer wrote: >On September 07, 2002 at 06:28:52, Rolf Tueschen wrote: >> >>Actually I was "defending" you against Sune. He advised you to consider the >>number of the digits, talking about measurement. From the internet files... >>What I was trying to say was that the speedup is a ratio and no measurement. > >Yes you _can_ convert from km/hr to miles/hr without losing digits, but >somewhere along the line there _has_ to be a measurement. >Whereever that is, that is where you should be careful. >Measuring nodes doesn't give a true picture of speedup, only an upper bound (as >mentioned). Time is the only relevant parameter AFAICS, and you _will_ have a >certain amount of uncertainty there, mostly because two runs doesn't produce the >same tree, but also because timing simply isn't easy to do accurately. Every >time I bench my program using clock() I get fluctuations within two percent, >don't understand why, it's all determanistic, but it is a fact none the less. >(this is perhaps not a big issue with a good timer?). Time quantization with a timer. IE when does the O/S update the time, and do you sample just before or just after that happens? cache/memory aliasing. Getting a "poor memory layout" can result in your program mapping to only a _part_ of your L1/L2 cache, effectively causing you to run with less cache from one run to another. interference. Another program "wakes up" and burns a few milliseconds here and there, sometimes. Memory issues. Some machines have memory that is "divided". Some of the memory is faster than the rest, and depending on how your program gets loaded into those two regions will influence speed. I am sure I have forgotten some. The cache/memory aliasing issue is the main one however. > >Say I kick a football 53 meters, that would be good measurement. >You don't need to know if it was 53.37634 or 53.24453 meters, 53 m is accurate >enough, because next time I'm probably not going to kick it 53 m, perhaps it >will be 57 m or 48 m depending on the wind conditions and how I kick the ball. >Same thing with parallel search since the tree changes from run to run. > >We could make the rule that only the best possible case is of interest, like in >the olympics. Then you can run the test 100 times and get lucky to get a speedup >of 2.0, so you have an algorithm that is theoreticly capable of doing a 2.0 >speedup? >I'm sure you can see why that is nonsense, only the average is of interest, IMO. I agree. Particularly since the variability can be significant for many positions. > >>And >>that depending of the positions (chess) this ratio would vary. So, here I give a >>first point to Vincent. To do exact research we must analyse how far chess does >>influence the speedup! I think that we could still continue the debate. Or is >>your paper already history and the actual problems are different ones? I had a >>different impression when reading V. First: Are you sure that 24 different >>positions would lead you to the same speed-ups? > >I am sure that they don't :) I am sure there are. Remember how many total positions there are in the game of chess. The speedups for each of those X positions will be distributed over the range 0...2, which is a many-to-one mapping, even if you compute speedups to IEEE 64 bit precision... there _must_ be lots of duplicates... > >-S. > >>What, if certain positions allow >>a gain for particular ncpu? Questions over questions. >> >>Rolf Tueschen
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.