Author: Robert Hyatt
Date: 10:33:14 11/21/01
Go up one level in this thread
On November 21, 2001 at 11:52:09, Slater Wold wrote: >On November 21, 2001 at 11:19:08, Robert Hyatt wrote: > >>On November 21, 2001 at 11:05:00, Slater Wold wrote: >> >>> >>>As I have found positions where the NPS search is 2.5x faster, but it solves the >>>solution in 4x faster than a single cpu. >>> >>>Dann and I had this "super" linear discussion before. >>> >>>Seems like it would even out, eventually. But like I said, I believe you. And >>>I'll do it to solution now. (But of course, I'll still look at the NPS!) :) >>> >> >> >>First, two cpus is going to have a _hard_ time searching 2.5x the raw >>nodes per second. I have no idea how that might happen, unless there is a >>bug in the node-counting that sometimes counts nodes twice. > >Sorry. I've seen positions where it will search 1.8x the NPS and solve it 4x >faster. That is not uncommon at all... > >I was just reversing your comment. > >>Second, "super-linear" can happen on occasional positions. But as you said, >>it will average out over multiple positions so that the speedup simply can not >>be >2.0 for two processors on average. I was in the middle of the super-linear >>speedup discussion. I hope it stays "at rest" now. :) > >I've seen it happen a time or two. I've found a solution one go, and can never >get it again. (Happened more than once with DJ7.) > >>I have seen several cases of spectacular speedups, but then I have also seen >>an equal number of horrible speedups. Bruce once sent me one that produced >>a particularly ugly result on Crafty, But I can't seem to locate the thing >>at present... > >I think I've only seen 1 or 2. But I have seen a LOT that are greater than the >speedup of the NPS speedup. In other words, it takes the SMP less nodes to find >the solutions, that the 1 CPU. > That is the classic super-linear speedup situation. bad move ordering corrected by the parallel search taking 'em two at a time. >>In any case, NPS is kind of like engine RPM. It should increase linearly with >>the number of processors, assuming the parallel algorithm is good at keeping >>both cpus busy all the time and doesn't have one (or more) sitting around >>waiting excessively. But RPM has nothing to do with vehicle speed, because >>of losses along the drive train. The MPH value (time to solution) is the thing >>that wins races (or games). > >HUM. Now you're picking a subject I am _very_ familiar with. RPM's and and MPH >aren't _DIRECTLY_ related. > >IE: > >If you have a car that has a 4.11 gear ratio with 351c.i. motor, that is getting >400 HP at 5750RPM, it SHOULD go 12's in the 1/4 mile. (Depending on weight.) >Let's just say, it goes 12.5 @ 119MPH. > >Now, let's say you install an aluminum driveshaft. Your RPM's are going to >increase. Same setup, same everything, it will probably get 400HP at 5900 RPM. >And if you run the 1/4 mile again, I would guarantee 12.3's at the SAME MPH. >Maybe, you'll get 1 or 2 more MPH. You're going .2 seconds faster, but the MPH >isn't changing. RPM doesn't = MPH, but the faster you can rev, the faster you >can get to that top MPH. Unless your gears are wacky. You do better than I do there. I've never seen an alum drive shaft increase RPM. I have seen it decrease the time to reach a particular RPM, but I don't see why it would increase the actual RPM since it doesn't take much energy to keep a driveshaft rotating, it just takes energy to accelerate it down the track, and energy to accelerate the RPM level of the shaft itself. Your above example can't work however, as you didn't change the rear end ratio, and if you reach a higher rpm you will _definitely_ reach a higher top speed as well. RPM and MPH are exactly proportional if everything else (tire diameter and final drive ratio) remains constant.
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.