Author: Uri Blass
Date: 07:32:09 09/05/02
Go up one level in this thread
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
This page took 0.01 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.