Author: Robert Hyatt
Date: 08:27:53 04/13/03
Go up one level in this thread
On April 13, 2003 at 08:32:37, Vincent Diepeveen wrote:
>On April 13, 2003 at 08:21:42, Vincent Diepeveen wrote:
>
>>On April 13, 2003 at 02:37:57, Tom Kerrigan wrote:
>>
>>>On April 13, 2003 at 01:04:52, Robert Hyatt wrote:
>>>
>>>>It _is_ pinned on SMT. The two logical processors are producing wildly
>>>>imbalanced results when using threads, vs using two separate processes. It
>>>>would appear to be cache-related...
>>>
>>>This is some sort of joke, right? You and Vincent see the same behavior, you
>>>have SMT and Vincent doesn't, and somehow the problem is with SMT?
>>>
>>>How much of the time are your threads idle, out of curiosity? If one thread is
>>>idle much more than the other, then of course that is going to skew your NPS.
>>>
>>>-Tom
>>
>>Of course both Crafty and DIEP are using YBW. I didn't checkout what bob does
>>here, but in past in DIEP i used to always let process 0 let the search start.
>>Nowadays that is not the case. The i/o thread picks the first process it can
>>get. All search processes are completely identical. This process then is
>>starting the search. That means the other CPUs idle when this process starts the
>>search.
>
>also read that 'idle' not in litterary sense. Letting them REALLY idle with
>sleep() or WaitForSingleObject, is at a REAL smp system (like dual K7) just too
>expensive. Latency to wake up processors is at sick high levels. 15 ms just like
>that. Imagine that because of the YBW search, you have to split initially like
>50-100 times a second. 15ms is death sentence. So 'idle' cpu's are spinning
>around until at a shared memory variable some flag is set. I let them do some
>arithmetic function for a 100 times while 'idling'.
If you do this right you won't split _that_ often.
time=35.97 cpu=381% mat=-1 n=80006982 fh=92% nps=2224k
ext-> chk=1487513 cap=353299 pp=32860 1rep=79236 mate=15135
predicted=3 nodes=80006982 evals=19493470
endgame tablebase-> probes done=0 successful=0
SMP-> split=1840 stop=163 data=15/64 cpu=2:17 elap=35.97
time used: 29.81
In the above from a game on ICC, in 35 seconds, I did 1800 splits total. The
deeper the search the better this becomes...
time=2:33 cpu=396% mat=0 n=282753699 fh=91% nps=1840k
ext-> chk=3046093 cap=1083298 pp=16735 1rep=192964 mate=3400
predicted=8 nodes=282753699 evals=114936261
endgame tablebase-> probes done=0 successful=0
SMP-> split=2683 stop=424 data=15/64 cpu=10:09 elap=2:33
time used: 8.29
time=4:03 cpu=396% mat=0 n=466004128 fh=90% nps=1911k
ext-> chk=3120074 cap=1773259 pp=60704 1rep=227466 mate=5595
predicted=9 nodes=466004128 evals=160300467
endgame tablebase-> probes done=0 successful=0
SMP-> split=5811 stop=950 data=18/64 cpu=16:06 elap=4:03
time used: 2:43
time=3:47 cpu=396% mat=0 n=421757405 fh=92% nps=1855k
ext-> chk=3436512 cap=1222511 pp=75583 1rep=186606 mate=3165
predicted=12 nodes=421757405 evals=149496490
endgame tablebase-> probes done=0 successful=0
SMP-> split=3524 stop=337 data=17/64 cpu=15:01 elap=3:47
>
>>In crafty that's also the case, but i do not know whether Bob always picks a
>>certain thread as first. If so then that might explain quite something.
>>
>>Measuring idle time with SMT is very hard to do objective, but of course you can
>>relatively check it out. Basically the problem is you do not know what the
>>maximum % is that i can get out of SMT, because it is dependant upon the other
>>process too.
This page took 0.01 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.