Author: Robert Hyatt
Date: 07:47:32 09/05/02
Go up one level in this thread
On September 05, 2002 at 10:32:09, Uri Blass wrote: >On September 05, 2002 at 10:05:05, Robert Hyatt wrote: > >>On September 05, 2002 at 00:25:58, Miguel A. Ballicora wrote: >> >>>On September 04, 2002 at 18:38:17, Dann Corbit wrote: >>> >>>>My take on the matter (in one paragraph): >>>>Robert wrote a paper on parallel speedup, showing a 1.7 increase for 2 CPU's (as >>>>derived from his more general formula). Vincent was unable to reproduce this >>>>sort of speedup, and thought the research was faulty. Robert agreed that the >>>>test set was limited and you won't always get that sort of speedup, but as an >>>>average (over a broad set of positions) that's about what he got. There has >>>>been some acrimony over whether superlinear speedups are possible. I think that >>>>the jury is still out on that one. >>>> >>>>At any rate, that's my take on the whole thing. >>>> >>>>Vincent always sees things in pure, jet black or gleaming, powder white. If >>>>something isn't terrific, then it is pure junk. While I think his mode of >>>>interesting is a bit odd, it's one of the things that make Vincent interesting. >>> >>>He crossed the line when he used the word "fraud" and "lie" >>>to describe a scientific paper without any solid proof (he only proved a flaw in >>>the presentation). Too serious. >>> >>>To be honest, I am embarrassed to be reading this thread. One side does not >>>recognize a flaw (it could be honest and I believe it, happens many times, big >>>deal) and the other makes pathetic accusations of fraud mixing it up with old >>>issues (Deep blue etc.). To top it all, ad hominem attacks. >>> >>>In this conditions it is impossible to discuss anything. >> >>While I understand what you mean, I don't see any major "flaw". As in the >>question I posed to vincent, if I ask you to measure the radius, diameter >>and circumference of a piece of pipe, once you have one, you can derive the >>others, but there will be a tiny accuracy issue. Because pi factors into >>the relationship among the three values, and what value do you use for pi? >>So even in something so simple as diameter vs circumference, there are a >>_set_ of possible diameters that will yield the same circumference, to some >>particular number of decimel places of accuracy. Yet in reality, only _one_ >>of those diameters can be the _real_ diameter. >> >>After showing Martin just how "bad" smp variability can be, that equates to >>a piece of pipe made out of some _very_ temp-sensitive material, so that the >>very act of touching it to measure it causes a change in the >>diameter/circumference. And that is what I see in SMP results _all_ the time. >> >>IE for a given actual time for a 16 processor test, and a computed speedup >>made by dividing the raw 1-cpu time by the raw 16-cpu time, you can now go back >>and re-compute the 1-cpu raw time. And there will be a _set_ of answers to >>that computation that still produce the same 16-cpu speedup. Is one of those >>pre-computed 1-cpu times (which can vary in the low order digits when the >>value is in the thousands) any better than another? Is one better because you >>computed it, and you actually observed it in the game under question? What if >>you run it again and you get _another_ one of the computed 1-cpu times, as it >>is easy to see the one-cpu time vary by a second or so over a long period, >>due to network traffic, interrupts, and so forth, maybe even a daemon process >>waking up for a moment to do something? >> >>My point? >> >>If you take a 16-cpu speedup, and a 16-cpu time, and use that to derive >>the set of 1-cpu times (measured only in seconds) you will get a set of >>N times that could produce that same speedup given the observed 16-cpu time >>and computed 16-cpu speedup. The inverse is the better way of thinking about >>this of course, because that 16 cpu time is just a "snapshot" that could vary >>dynamically, and as the 16-cpu time varies, so would the set of 1-cpu times >>that would still produce that same speedup. >> >>In other words, there is a _lot_ of inaccuracy already. So the question >>becomes, "why compute some of the times, why not observe them all?" That is >>"the" question here. And it is one I am not sure I can answer yet. I have >>gotten "closer" to the disk failure date. From info in my files at the office. >> >>I bought a Gateway G6/200 (pentium pro 200) when they first came out. I think >>Bruce got his a month or so before me. In early 1996, I had a disk crash, >>and called gateway for a replacement (this is the part I have docs for as you >>will see shortly). They sent one but when it arrived, it was a 68-pin wide >>scsi drive, while the machine they had sold me 2 months earlier was a 50-pin >>narrow scsi drive (this machine had 4 4.5 gig scsi drives). I called them to >>tell them about the "error" (I couldn't use that drive with my scsi controller) >>and they responded "we no longer have any narrow scsi stuff, we have migrated >>to wide scsi." I responded "great, so I have a machine 2 months old, that >>cost me $5,000, and you can't get me a replacement drive? Mark me off the >>gateway customer list (I used to order 20-30 machines _per year_ for our >>department labs)." That got their attention, they sent me three more wide >>scsi drives and a new controller. So I have at least homed in on when I lost >>"the world". And that suggests that we _had_ to reconstruct the data as best >>we could, although neither of us can say "yes that was the reason" with 100% >>reliability. I mainly remember trying to get Crafty back up to speed. I was >>getting ready for the WMCCC event, and was not releasing new versions. As a >>result, when the disk went down, I lost everything, and had to back up to the >>last released version and start over, trying to remember the changes I had >>made. >> >>I don't know when I started back to work on the dts paper, because the panic >>about the WMCCC and losing things is the thing that I _really_ recall (not >>to mention class assignments, handouts, etc.) But it is certainly within >>reason to think that led to the time computations. As I have said all along, >>the node computation was unavoidable from the start... >> >>So, as far as I am concerned, there is _nothing_ "false" in the DTS paper. I >>computed the speedups in the normal way, using raw data, back in early 1994 >>after the tests were run. That was the "critical data" presented in the paper. >>Later, we extrapolated the nodes when they were asked for, and it would seem >>that we extrapolated the times at the same time. >> >>That is about all I can remember, so far. I don't consider the "node" data to >>be very interesting at all, and the "time" data is dynamic enough due to the >>variability in speedup that any value I published, whether it be extrapolated or >>observerd, could likely _never_ be repeated again. As a new test run would >>certainly vary by seconds if not much more (another thread in this discussion >>shows some wild behavior on kopec 2, and some rock-solid behavior on kopec 3, >>to illustrate this point.) >> >>I don't see it as being a "fraud" at all, but then I'm not Vincent. I think >>the concept of "if you can't make yours look better, then make someone else's >>look worse" is extremely sad, of course. But he will continue to do that on >>all fronts. "crafty's eval is simple". "fritz knows shit about chess". >>"tiger is stupid in endgames." We've all seen those comments over and over. >>As well as "diep has the most sophisticated eval of any chess program" or >>"diep is the strongest program in the world at correspondence time controls". >> >>What more could anyone say? >> >>Will Crafty ever approach CB's DTS speedup? I doubt it, because I am not >>willing to give up the recursive search, which would be the first thing to >>go. If I had high expectations of running on a 32 cpu machine all the >>time, then I certainly might consider it. But I suspect that I will be >>using a quad for the foreseable future, with maybe an 8-way or 16-way >>box on rare tournament occasions. I'm old enough to try to avoid >>headaches, which you get with non-recursion when you try to read it later. >> > >I do not think that the numbers are important here. >The numbers may be interesting only when we are sure that searching for one >processor cannot be improved and it is not the case. > >If somebody use a bad algorithm for one processor then it is even possible to >get super linear improvement. > >I suspect that searching for one processor can be improved significantly >so there is no reason to care if you get 1+0.9(n-1) for n processors or >1+0.6(n-1) for n processors. > >improvement in the evaluation or improvement in the search rules are clearly >more important. > >Uri Maybe or maybe not. You are ignoring "compounding". IE spending a year to get .1 improvement in serial search? Or spending a year to get .05 * N improvement in the parallel search where N is large? I don't think our serial searches are very bad. IE I get the best move first 92% of the time. I'm not sure how much farther I can go with that as there will _always_ be flaws that only a deep search exposes, when you sort moves in some arbitrary way. I don't say that improvements are not possible. And perhaps forward-pruning ideas are one possible way. But working to make the parallel search traverse the same tree as the serial search is also going to pay off in a big way...
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.