Author: Robert Hyatt
Date: 06:56:48 06/29/99
Go up one level in this thread
On June 29, 1999 at 09:07:40, Ernst A. Heinz wrote: >On June 28, 1999 at 18:19:59, Vincent Diepeveen wrote: > >> [...] and that's kind of tough >>in the parallellism i use (which is an improved cray blitz version). > >Vincent, > >Your above statement is most amusing. Nobody else would ever call his >buggy and not even deadlock-free parallel search an "improvement". >Why don't you first establish the soundness of your implementation >before measuring its "phenomenal" effectiveness ... > >You surely know that anything is deducible from unsound hypotheses. > >> [...] >> >>The speedup of the 4x400Mhz xeon with 450Mb hash compared to >>a PII-450 NT is about 5 times for DIEP, as the speedup of 4 processors >>for DIEP is 4.06 . The more difficult a position is the >>bigger the speedup. Speedups over 10 times at 4 processors are not an >>exception for DIEP. Now this is theoretical not possible will some say. >>Dead wrong. It is. > >So-called "superlinear speed-up" due to cache and memory effects is indeed >possible but highly unlikely in the case of parallelizing a *sophisticated* >alpha-beta searcher. However, "Diep" may just not be so super-sophisticated >as you constantly claim. Do you also get such extreme improvements for your >sequential program version when adding processor cache and main memory on >a single-CPU system? > >The most likely explanation for your speed-up observations is that your >buggy and not even deadlock-free parallel search is unsound and, therefore, >lets you deduce and measure anything ... (see above) > >=Ernst= Actually, super-linear speedups happen all the time, in selected problems. Bruce and I have been comparing notes on one particular set of positions, and for me, one of the positions runs 10x faster with 4 cpus. And a couple of others run 5-6 times faster than with 1 cpu. But, of course, on average, the overall speedup is always <= 4 (3.2 in the case of current crafty, while Cray Blitz was closer to 3.7). This is generally explained by poor move ordering, where in parallel you search the best branch before you finish searching non-best branches... But you are really right... until a program runs reliably (and this takes quite a while to reach) measuring performance is not very useful, because the performance of a bug-ridden program can be _very_ misleading. As I have worked on the parallel search in Crafty I have run into this many times... Consistent speedups > 4 imply a very inefficient sequential search, move- ordering wise.
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.