Author: Robert Hyatt
Date: 08:01:07 04/11/03
Go up one level in this thread
On April 11, 2003 at 09:10:39, Vincent Diepeveen wrote: >On April 10, 2003 at 14:19:30, Robert Hyatt wrote: > >the same old trick again. I ignore your results here. I need logfiles or i do >not believe a thing. You have committed too much academic fraud here to believe >you on your blue eyes. > >Sorry for that. Then I suggest you fall thru your butthole and hang yourself. > >>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??? >> >> >> >> >> >> >> >> >>> >>>1.1 speed is what you get out of single P4 with smt. >>> >>>1.7 / 2 * 1.1 = 0.935 which is slower than single cpu. >>> >>>Which is my point. >> >>And it is wrong, which is _my_ point. See real data above for contradiction of >>hand waving numbers. >> >> >> >>> >>>> >>>>> >>>>>If you first slowdown crafty in order to then get a better speedup from SMT >>>>>that's your choice. >>>> >>>>I didn't "first slowdown crafty". The SMP version runs just as fast as the >>>>non-SMP >>>>version, so I have no idea what you are talking about... >>>> >>>> >>>>> >>>>>>On April 09, 2003 at 17:02:34, Vincent Diepeveen wrote: >>>>>> >>>>>>>On April 09, 2003 at 11:52:48, Charles Worthington wrote: >>>>>>> >>>>>>>it shows that SMT is still in its childhood with the current P4s. Getting a % or >>>>>>>10 in nps speed from hyperthreading is not enough to get a positive speedup. >>>>>>> >>>>>>>Consider this. >>>>>>> >>>>>>>suppose fritz gets 1.7 speedup out of 2 processors. >>>>>>>suppose hyperthreading speeds up 10%. >>>>>>> >>>>>>>Then what is actual speedup? >>>>>>> 1.0 * 1.10 (speedup) * (1.7 / 2.0) = 0.935 which is SLOWER than 1.0 without. >>>>>>> >>>>>>>Easy math. >>>>>>> >>>>>> >>>>>>Poor math. If it gets 1.7 out of a dual, and the single cpu version does 1M >>>>>>nodes per >>>>>>second, and hyper-threading brings that to 1.3M, then the effective speedup will >>>>>>.7 of >>>>>>that extra 30% which turns into 1.21 X faster in terms of time to solution. >>>>>>That does >>>>>>assume that SMT makes his raw speed 1.3X faster, and that with two equal >>>>>>processors >>>>>>his speedup is 1.7. >>>>>> >>>>>>Your math is bad. >>>>>> >>>>>> >>>>>>>>I ran the Deepfritzmark and Shreddermark tests with hyperthreading disabled then >>>>>>>>enabled with some very confusing results that I am hoping someone can help >>>>>>>>explain: >>>>>>>> >>>>>>>>Test set #1 Hyperthreading Disabled, 64MB Hash, Engine Parameters @ default >>>>>>>> >>>>>>>>Shredder 7.04: Shreddermark: 2227 +- 0 (1.5s) 705kN/s >>>>>>>> >>>>>>>>Deep Fritz 7 : Deepfritzmark: 2724 +- 44 (3.1s) 2252kN/s >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>Test set #2 Hyperthreading Enabled, 64MB Hash, Engine Parameters @ Default >>>>>>>> >>>>>>>>Shredder 7.04: Shreddermark: 2227 +- 0 (1.5s) 803kN/s >>>>>>>> >>>>>>>>Deep Fritz 7 : Deepfritzmark: 2476 +- 0 (3.2s) 2555kN/s >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>Test set #3: Hyperthreading Enabled, 32 MB Hash, Engine Parameters @ Default >>>>>>>> >>>>>>>>Shredder 7.04: Shreddermark: 2784 +- 0 (0.4s) 907kN/s >>>>>>>> >>>>>>>>Deep Fritz 7: Deepfritzmark: 2476 +- 0 (3.4s) 2532kN/s >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>Test set #4; Hyperthreading enabled, 16MB Hash, engine parameters @ default >>>>>>>> >>>>>>>>Shredder 7.04; Shreddermark: 2784 +- 0 (0.4s) 1008kN/s >>>>>>>> >>>>>>>>Deep fritz 7: Deepfritzmark: 2476 +- 0 (4.5s) 2544 kN/s >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>This is somewhat confusing as Fritz scored the highest fritzmark with >>>>>>>>hyperthreading_disabled_ even though his kN/s were_far_lower. Shredder scored >>>>>>>>far better with it_enabled_ both in result, speed, and time to solution. >>>>>>>>Also Shredder seemed to benefit more from the smaller hash sizes where Fritz >>>>>>>>seemed relatively worsened by them. Does anyone have any insight as to these >>>>>>>>seemingly contradictory results? And would I be better to run Deep Fritz with >>>>>>>>the hyperthreading diasabled even though his kN/s is considerably lower? >>>>>>>> >>>>>>>>Charles
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.