Author: Vincent Diepeveen
Date: 06:10:39 04/11/03
Go up one level in this thread
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. >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.