Author: Robert Hyatt
Date: 06:56:59 10/06/03
Go up one level in this thread
On October 06, 2003 at 06:15:58, Tom Kerrigan wrote: >On October 04, 2003 at 23:54:43, Jeremiah Penery wrote: > >>On October 04, 2003 at 22:27:45, Tom Kerrigan wrote: >> >>>You're right, the #s do work out pretty well, but that must mean both threads >>>are bouncing around different logical processors frequently, otherwise there'd >>>be a disparity in the node counts of each thread. This doesn't seem likely to me >>>but I guess it's not impossible. I wonder if there's a way to keep track of >>>which thread is running on which processor. >> >>The threads really do hop around the processors. You wrote previously that a >>process should stay on the same processor until 'something odd happens' - in >>other words, until something pre-empts the process. It's very frequent that a >>part of the kernel, or a service, or something else with default high+ priority >>gets scheduled for some miniscule fraction of time, so it will bump your process >>to another processor. If you raise your program's priority to realtime and run >>two threads, you should be able to get more stable results in this regard. > >Wouldn't this result in a lot of cache thrashing that would slow the program >down? If I run two copies of my program simultaneously they each run exactly as >fast as one copy. (Which is interesting because both copies use hash tables--I >suppose the hash table probes are infrequent enough to not cause many FSB >collisions.) > >-Tom There are multiple issues. The APIC chooses which CPU to send an interrupt to (it appears to send all interrupts to CPU#0 on my dual 2.8 running 2.4.21 linux.) An interrupt is definitely going to dislodge a process for a brief period of time. Linux has some specific kernel fixes to prevent too much "bouncing". You are correct that bouncing two different processes between two physical processors tends to thrash cache. Bouncing two threads does not since the threads all share the same virtual and real address space. Bouncing on two logical processors is another issue since two logical processors share a cache between them and since threads share everything, there is no problem there at all other than the system overhead of moving them between processors. Hashing is outside L1/L2 anyway, but you have to think about processor affinity and whether it is important or not. And the answer is "maybe". For threads? No. For separate processes using separate virtual address spaces? Yes, it is important and bouncing is bad.
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.