Author: Robert Hyatt
Date: 08:45:45 07/20/05
Go up one level in this thread
On July 19, 2005 at 18:29:16, Vincent Diepeveen wrote: >On July 19, 2005 at 15:04:38, Joachim Rang wrote: > >Joachim, there are 2 important things in parallel search: > a) scaling > b) speedup > >First important goal is good scaling. At big supercomputers, assuming you use >YBW as the parallel algorithm, your ONLY goal is a good scaling. > >Vincent The real problem here is that this is using "scaling" improperly. In pure parallel programming theory, "scaling" simply means "how well does performance increases track the number of processors?" Or, as you add more processors, does the performance continue to improve? And in parallel theory, this performance is _always_ about "time to solution" and nothing else. Which in our case is "time to a specific depth". There are plenty of algorithms that peak at some number of processors, and adding more gets no more performance. In computer science, these algorithms are said to "not scale well". The real issue in scalability is "will this produce good performance on a large number of processors, or just on a small number?" A program that "scales well" will run on a large number of processors, while a program that "scales poorly" will not. Unfortunately we have corrupted the term "scaling" to apply to NPS scaling only, while the _real_ scaling term applies to _total performance_ not just raw NPS. not the first time a precise parallel theory term will be corrupted I suspect... > >> >>> >>>Please post the nodes per second for 1 and more threads obtained when searching >>>the below position for around 60 seconds. >> >>nodes per second? There is no worse indicator how well a program scale than >>nodes per second. It is easy to achieve perfect scalablity by simply letting all >>threads calculating the same. >> >>To measure scalability one has to invest quite an effort. The Hydra-Team does it >>with a special testsuites which take about 24hours to run. The cheap approach >>would be: >> >>Take 10 positions and note the timetodpth for depth say 18. Than calculate the >>average timetodept18 and compare. >> >>Even that approach is not perfect since a 18ply-search on a single processor has >>a different quality than on a dual. >> >>regards Joachim
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.