Author: Robert Hyatt
Date: 11:27:22 01/15/04
Go up one level in this thread
On January 15, 2004 at 13:50:47, Tony Werten wrote: >On January 15, 2004 at 11:17:24, Robert Hyatt wrote: > >>On January 15, 2004 at 08:41:08, Tony Werten wrote: >> >>>On January 14, 2004 at 23:25:52, Robert Hyatt wrote: >>> >>>>On January 14, 2004 at 16:20:37, Frank Quisinsky wrote: >>>> >>>>>Hi there, >>>>> >>>>>OS=Windows Professional SP1a: >>>>> >>>>>Crafty.rc >>>>>mt=1 ... or 2, 4 possible ... of course 3 isn't possible :-) >>>>>computer >>>>>hash 192M >>>>>hashp 24M >>>>>cache 4M >>>>>resign 9 >>>>>tbpath=c:\Chess\nalimov >>>>>egtb >>>>> >>>>>--- >>>>>Crafty 19.09: >>>>>Total nodes: 85506521 >>>>>Raw nodes per second: 1030199 >>>>>Total elapsed time: 83 >>>>>SMP time-to-ply measurement: 7.710843 >>>>>--- >>>>>Crafty 19.09 SMP MT=1 >>>>>Total nodes: 85506521 >>>>>Raw nodes per second: 1017934 >>>>>Total elapsed time: 84 >>>>>SMP time-to-ply measurement: 7.619048 >>>>>--- >>>>>Crafty 19.09 SMP MT=2 >>>>>Total nodes: 91665964 >>>>>Raw nodes per second: 1553660 >>>>>Total elapsed time: 59 >>>>>SMP time-to-ply measurement: 10.847458 >>>>>--- >>>>>Crafty 19.09 SMP MT=4 >>>>>Total nodes: 100226709 >>>>>Raw nodes per second: 2132483 >>>>>Total elapsed time: 47 >>>>>SMP time-to-ply measurement: 13.617021 >>>>> >>>>>Not easy to understand for me: >>>>>MT=1 = 1017934 = + ~ 53% = MT2 >>>>>MT=2 = 1553660 = + ~ 37% = MT4 >>>>>MT=4 = 2132483 >>>>> >>>>>MT=1 to MT=2 must be only Multi-Threading from the first processor! >>>>>20-30% but not 53% >>>> >>>> >>>>You are not understanding hyper-threading. You have two physical >>>>processors, and each is divided into two logical processors, giving you >>>>what _appears_ to be 4 cpus. When you run two threads, how do you >>>>guarantee that each thread runs on a different physical CPU? Answer: >>>>You can't. So you might get both threads on one physical processor >>>>or one on each physical processor, or they might bounce between the >>>>two states. >>>> >>>>The moral: >>>> >>>>don't _ever_ run two threads on a SMT-enabled dual. 3 is fine, as obviously >>>>two will be on one physical processor and one will be on the other. Four is >>>>fine. But _not_ two. >>>> >>>>As operating systems become aware of this, they will fix it. There are linux >>>>patches that solve this, for example. I don't know about windows. >>> >>>I think this should do the trick: >>> >>>The SetThreadIdealProcessor function is used to specify a preferred processor >>>for a thread. The system schedules threads on their preferred processors >>>whenever possible. >>> >>>DWORD SetThreadIdealProcessor( >>> >>> HANDLE hThread, // handle to the thread >>> DWORD dwIdealProcessor // ideal processor number >>> ); >>> >>> >>>Parameters >>> >>>hThread >>> >>>Handle to the thread whose preferred processor is to be set. The handle must >>>have the THREAD_SET_INFORMATION access right associated with it. For more >>>information, see Thread Objects. >>> >>>dwIdealProcessor >>> >>>Specifies the number of the preferred processor for the thread. A value of >>>MAXIMUM_PROCESSORS tells the system that the thread has no preferred processor. >> >> >>OK. In Unix systems, what library do I include to access that function? > >ifdef WINDOWS > SetThreadIdealProcessor >else > No need, the os will be fixed >end Actually that is a valid NUMA issue. A thread has local data. That is on just one processor. You _really_ want that thread glued to that processor to avoid extra memory latency. Eugene did this for windows. I've been playing with it on Linux, but getting libnuma to work reliably is not so easy as the kernel guys are changing the NUMA interface faster than the libnuma guys can keep up, at the moment. > >Tony > >> >>:)
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.