On Fri, 20 Nov 1998, Neil Conway wrote: > [EMAIL PROTECTED] wrote: > > I have a Tyan S1832DL Tyger 100 running with dual 450 MHz PII for a bit > > more than a week. First with 2.0.35 now with 2.0.36. In the short > > observation time it was running stable with both kernels, although there was > > a huge difference in number crunching performance (better for 36). I have > > 512M memory. No problems seen with this one so far either. > > Huge increase for 36 in number-crunching ? Are you very sure ? > > Number crunching programs which are highly CPU-bound (i.e. not doing I/O > or paging) should see ~= 0 difference between any set of kernels, for > the simple reason that they spend ~= 0% of their time in the kernel in > the first place. If a program spends say 1% of its time in the kernel, > and you improve the kernel by three orders of magnitude, how much faster > does the program run ? ~100/99... See what I mean? Well, Alan's remarks about the VM improvements gave me pause (and still do, a bit) because for big code anything that improves paging efficiency might well make a "huge" difference. However, being smitten with curiousity and believing that one benchmark is worth a thousand words of analysis, I just went and upgraded my longest running SMP system (115 days of load average never below 1 and usually above 2, with a kernel that I KNOW was broken -- 2.0.35 with a mightily hacked 5.1.0pre-something aic7xxx driver -- take THAT WinNT ;-) to 2.0.36 and ran my own personal benchmark -- the one that times my own numerical (Monte Carlo, profiled to a mixture of maybe 70% float to 30% integer) code. I mean, what other meaningful benchmarks are there:-)? Results over ten runs: I didn't even bother to actually add them up. The ranges on two ABSOLUTELY IDENTICAL systems, one running 2.0.35 and one running 2.0.36 were around 1% in width at roughly half a second out of fifty (eyeballed variance of <1% of runtime, if you like) and I looked at around ten jobs (stdev of perhaps 0.3%) and the means had to come out within ~sigma. If anything, the 2.0.36 numbers looked a bit worse, but with this small a sample and means well within 1% it doesn't mean anything either way. I think that I can confidently state that the floating point rates between 2.0.35 and 2.0.36 are >>very<< unlikely to differ by more than 2% (six sigma, to compensate for the small sample size) and is likely to be less than 2 sigma. These jobs were tiny and did NOT stress out the memory subsystem or the cache. If any improvements were made that really did significantly alter efficiencies in these two arena's, perhaps a big difference could be observed, but it isn't really a difference "in floating point" then, it is a difference in the memory subsystem efficiency and should improve all code, integer or float, that is memory intensive. rgb "Let's Test, Not Talk" "Awwww, C'mon." "Well, OK, but at least let's test FIRST and talk about the results afterwards..." Robert G. Brown http://www.phy.duke.edu/~rgb/ Duke University Dept. of Physics, Box 90305 Durham, N.C. 27708-0305 Phone: 1-919-660-2567 Fax: 919-660-2525 email:[EMAIL PROTECTED]
