Author: Gian-Carlo Pascutto
Date: 23:39:17 08/08/02
Go up one level in this thread
On August 09, 2002 at 00:00:31, Robert Hyatt wrote: >This is useless testing. You have two processes running and only one cpu. >At any instant in time, one can hold a lock and the other can be spinning >waiting on the lock. The process scheduler has no idea which process is >doing real work (the one holding the lock) or which is spinning (the one >waiting on the lock). So you burn cpu cycles needlessly. If you have an >idle loop (as I do using 'thread pools') then the same problem happens >there... the scheduler can't tell which is actually searching for a position >where the others can help, and which are spinning waiting on work doing nothing >useful... I must be missing something here, because that is exactly what I'm aiming at. I want each process to get as close to 50% cpu utilisation as possible. That means that they _have_ to burn cpu cycles even if they are not doing anything. Spinning while waiting on a lock is lost performance when running parallel, so I want to get loss there as well on the single cpu. If I wouldn't do the busy-spin, and never split, my parallel stuff would finish just as fast as the serial one, and I'd erronously conclude I've got a 2.0 speedup. If I busy spin, I'll finish in double the time, and correctly conclude no (1.0) speedup. -- GCP
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.