Author: Eugene Nalimov
Date: 11:14:11 07/27/00
Go up one level in this thread
Tom, next time please read the available papers before jumping into discussion. You can come to my office, as I have copy of the IEEE Micro article. Or you can use MS Library access to IEEE site to get a PDF copy of it. Or you can browse past CCC postings, as somebody (Scott Gasch?) wrote about Hsu's lecture he gave at MS. I and Bruce Moreland attented this lecture, too. At the time Hsu tried to get support for his PC-based chips, so the lecture was mainly self-promotional, but there were some technical details, too. I also sent report on Campbell's lecture on DB (that he gave at MS some years ago, too) to r.g.c.c, but it looks that Deja archives are broken for now, so it's not available. It's well-known at CCC that you and Bob do not like each other, but you at least can be polite, especially when Bob is right in technical details. Eugene On July 26, 2000 at 17:22:38, Tom Kerrigan wrote: >On July 26, 2000 at 14:55:04, Robert Hyatt wrote: > >>My argument won't "go south". 480 processors is the right number. 2.2M nps >>per processor (average) is the right number. 480 * 2.2M is > 1B. Which is >>a right number. 200M is his 'effective number' which no other parallel >>program is reporting, they _all_ report the total nodes / total time, to >>get a raw NPS. Hsu's RAW nps is around 700M, based on his statement in several >>papers that he can drive the chess chips at about 70% duty cycle using the >>current SP2 configuration. Or factoring in his 30% efficiency, he claims 200M >>which is a very realistic (and conservative when compared with every other >>parallel program's NPS) number. >> >>Unlike yourself, I try to not manufacture data, nor twist it to suit my own >>purposes. I simply report _factual_ numbers for DB, numbers you could easily >>verify _if_ you really wanted to. But that would take the fun out of the >>constant arguing, wouldn't it??? > >Okay, let's verify. I just went to IEEE's web site and searched through the >abstracts of all the DB articles. This is where you suggested to look, right? >Here are some direct quotes: > >"Because Deep Blue can evaluate 200 million moves per second, one observer said >it had won by packing 380 years of human thought into three minutes." > >"The IBM Deep Blue supercomputer that defeated World Chess Champion Garry >Kasparov in the 1997 historic match had 480 custom chess chips in the system." > >"At 2 to 2.5 million chess positions per second, one chess chip is equivalent to >a 100 billion instructions/sec supercomputer." > >"Now it has the ability to calculate 50 to 100 billion moves within three >minutes." (Deeper Blue) > >"Deep Blue is a 32-node IBM Power Parallel SP2 high performance computer. Each >node of the SP2 employs a single microchannel card containing eight dedicated >VLSI chess processors, for a total of 256 processors working in tandem." (seems >to imply Deeper Blue) > >So there seems to be some confusion about how many processors were in Deeper >Blue, but one article says 480, so you may be right. > >But the point of main contention here, namely 1 billion nodes per second, is not >supported anywhere. > >In fact, it's directly contradicted by two articles. One article says 200M NPS. >The other article says 277M to 555M NPS. Even the IBM web site says 100M, and >you'd think it would have the most optimistic number. > >So who is manufacturing data? It sure doesn't look like Chris. > >Remember not long ago when I was quoting Hsu's estimate of how many general >purpose instructions it would take to search a DB node? And you told me that Hsu >obviously didn't know what he was talking about and the estimate was worthless? >Well, the estimate was published in the IEEE journal by the man who built the >chip. It was staring you right in the face, and against all common sense you >chose to ignore it. So who is being academic here? It doesn't look like you. > >-Tom
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.