Author: Robert Hyatt
Date: 13:43:15 04/10/03
Go up one level in this thread
On April 10, 2003 at 14:42:12, Keith Evans wrote: >On April 10, 2003 at 14:19:30, Robert Hyatt wrote: > >>On April 10, 2003 at 11:11:52, Vincent Diepeveen wrote: >> >>>On April 10, 2003 at 11:07:06, Robert Hyatt wrote: >>> >>>>On April 10, 2003 at 08:44:18, Vincent Diepeveen wrote: >>>> >>>>>On April 09, 2003 at 17:58:21, Robert Hyatt wrote: >>>>> >>>>>as usual you were asleep when replying. i did math for a single cpu. that >>>>>extrapolates to more cpu's as well. >>>> >>>>I did math that extrapolates to _everything_. >>>> >>>>If I get 1.7X speedup for two cpus, I will get _some_ speedup no matter how slow >>>>the >>>>second processor is. >>>> >>>>Which was my point. >>> >>>with SMT that is not the case. the second cpu in SMT delivers somewhere between >>>0% and 20%. >>> >>>If it is 10% like it is for most programs then: >> >> >>Here is some _real_ data as opposed to your imaginary data. >> >>I took the last four positions you wanted me to run, which I assume you thought >>were bad cases for Crafty. >> >>I ran them three times with SMT off, using mt=2. >> >>I then ran them three times with SMT on, using mt=4. >> >>Here are the results, giving the time for each of the positions, and the raw NPS >>searched >>for each position. >> >>-------smt=off-------- >>---------mt=2--------- >>time=57.12 nps=1617k >>time=57.15 nps=1625k >>time=1:00 nps=1617k >>average=58.09 seconds >> >>time=32.02 nps=1807k >>time=31.85 nps=1814k >>time=32.32 nps=1805k >>average=32.06 seconds >> >>time=1:00 nps=1468k >>time=1:09 nps=1486k >>time=1:06 nps=1481k >>average=65 seconds >> >>time=51.68 nps=1711k >>time=53.97 nps=1705k >>time=54.73 nps=1699k >>average=53.46 seconds >> >>-------smt=on--------- >>---------mt=4--------- >> >>time=54.13 nps=1981k >>time=56.10 nps=2041k >>time=53.43 nps=2000k >>average=54.5 seconds >> >>time=26.99 nps=2230k >>time=25.71 nps=2303k >>time=26.40 nps=2240k >>average=26.37 seconds >> >>time=1:04 nps=1798k >>time=1:00 nps=1835k >>time=1:20 nps=1778k >>average=68 seconds >> >>time=45.84 nps=2069k >>time=44.76 nps=2135k >>time=49.78 nps=2073k >>average=46.79 seconds >> >>You can analyze the data any way you want. SMT on with mt=4 is faster for my >>program >>than SMT off with mt=2, contrary to your statements. Position three had one >>run that was >>slower by a significant margin than the others with SMT on. This is not that >>uncommon. >> >>But overall, SMT is _clearly_ a win. Regardless of all that handwaving, >>"proofing" and >>whatever else it is you claim to be doing. >> >>Position 1runs 1.07X faster with SMT on. >>Position 2 runs 1.22X faster with SMT on. >>Position 3 runs .96X faster (slower) with SMT on. >>Position 4 runs 1.14X faster with SMT on. >> >>If you do smoothing, to remove the oddball time from position 3 (remove the one >>point >>that took longer than any other by a significant margin) and you remove the >>largest value >>from the SMT=off case as well for balance, you get 63 secs average for SMT off, >>and 62 >>seconds average for SMT on, for a couple of percent improvement for SMT on. >> >>As I said, rather than flapping arms, and doing bogus math, it is _much_ easier >>to simply >>run the tests and look at the numbers. Something I always do, and something you >>_never_ >>seem to do. >> >>I wonder why that is??? > >Um... Because you always run them for him ;-) > >Do you really believe these positions were handpicked to make Crafty look bad? Who knows. They came from the "hashing" discussion last week. I ran the first few BT positions. He said they were "optimal" for crafty and these were harder. He also suggested I try the parallel search measurements on them, so I _suspect_ that for whatever reason he _thought_ they might be bad for me. They were fine for hashing and the data matched the positions I had used perfectly so that argument went down the toilet. The SMT on data is what I would expect, so that argument (of his) went down the toilet... >And if so then do you expect a larger performance increase for more typical >positions? I don't really know. I'm a little leery of these results myself, because at present there is an unexplained problem in Crafty on the PIV when using threads. And it is not outside the realm of possibilities that when that "bug" is fixed, SMT might work better or worse for me than it does now. But at the present, it certainly produces a boost in performance, regardless of his hand-waving... > >What machine were you running these on? I have a Dell PowerEdge 2650 with dual >2.8 GHz Xeons. (No I haven't run crafty on it yet, but would consider it if >there were just a simple script to get those results.) I'm using a dell poweredge 2600, with dual 2.8's. But this is the 400mhz FSB version, not the 533. Here are the two files you need: name this file "crafty.run" po off st=9999 hash=96M hashp=20M display nomoves test crafty.test end name this file "crafty.test" title pos1 setboard 2rq1rk1/pb3ppp/1p2pn2/4N3/1b1PPB2/4R1P1/P4PBP/R2Q2K1 w - - 0 2 sd=11 solution d5 title pos2 setboard 2r1r3/p3bk1p/1pnqpppB/3n4/3P2Q1/PB3N2/1P3PPP/3RR1K1 w - - 0 2 sd=11 solution Rxe6 title pos3 setboard rqr3k1/pp1bppbp/2np1np1/8/2BNP1P1/2N1BP2/PPPQ4/2KR3R w - - sd=11 solution a1a1 title pos4 setboard r1bqr1k1/pp1p1ppp/5n2/1N2n3/2P1PB2/6P1/PP1Q1K1P/4RB1R b - - 0 1 sd=11 solution d7d6 exit To run the thing, type this: crafty mt=2 <crafty.run and wait. Or crafty mt=4 <crafty.run It takes about 3 minutes or so to run. I generally run 'em 3-4 times each to get an average..
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.