Re: Newbie query re multithreading
Re: Newbie query re multithreading
- Subject: Re: Newbie query re multithreading
- From: "McLaughlin, Michael P." <email@hidden>
- Date: Tue, 18 Aug 2009 13:19:29 -0400
- Acceptlanguage: en-US
- Thread-topic: Newbie query re multithreading
On 8/18/09 11:34 AM, "Bill Bumgarner" <email@hidden> wrote:
> On Aug 18, 2009, at 7:25 AM, McLaughlin, Michael P. wrote:
>
>> 1) With 1 CPU (NSOperation not used), I get 50% of CPU-time devoted to
>> auto_collection_thread which I presume means Garbage Collection. Is
>> this
>> normal? It seems excessive.
>
> It sounds like your algorithm is doing a tremendous amount of memory
> thrashing as it runs; allocating and deallocating tons of objects.
> Under GC on Leopard, the collector will spend a ton of CPU cycles
> trying to keep up.
I suspect that this much is true. This code contains a huge number of
matrices and vectors, allocated locally and allowed to go out of scope
without explicit freeing (given GC). I am not sure of the internals of the
Eigen library but that seems to be nearly all templated headers.
>
>> 2) With 2 CPUs, I get 26% of CPU-time for auto_collection_thread and
>> another
>> 26% for mach_msg_trap --> CFRunLoopSpecific (apparently back to Carbon
>> again).
>
> CF is CoreFoundation, not Carbon.
Yes, but CFRunLoopSpecific leads to RunCurrentEventLoopInMode which is
HIToolbox (supposedly Carbon).
> Do you have something in your concurrent code that is sending messages
> back to the main event loop or posting events to other thread's run
> loops? This can be problematic, too, in that you can end up
> consuming tons of CPU cycles in message passing.
At the end of each NSOperation, there is a single enqueueNotification just
before the thread main() exits [for higher-level bookkeeping]. I use
enqueue instead of post because it is asynchronous. Otherwise, the calls
would pile up and the caller stack frame would not terminate until the whole
program was finished.
> If your compute threads are syncrhonously -- waitUntilExit: YES'ing --
> between threads, you can quite easily see a "reverse scaling"
> performance profile as you are now.
Not really sure what this means. The caller, at each timestep, looks like
this:
Nwaiting = numProcessors;
for (int op = 0;op < numProcessors;op++) {
compOperation *thisOp = [[compOperation alloc] initWithCompData:&compData
ID:op
step:timeNdx
user0:firstUser[op]
userN:lastUser[op]
queue:[NSNotificationQueue defaultQueue]];
[opQueue addOperation:thisOp];
}
More-or-less copied from Apple's NSOperation sample code. As noted, each
operation enqueues an "I'm finished" message to this caller. Nwaiting is
decremented upon receipt. compData is a read-only structure containing
global data.
>
> Do you have access to Snow Leopard? If so, use it. The tool chain
> for analyzing and improving concurrent applications is vastly
> improved. Even if you are going to continue to target Leopard, the
> analysis and debugging improvements will make your job easier.
>
Yes and no. I do have it, at home, but have not installed it because I have
only a single Intel Mac and I was unsure of the feasibility of installing
two Developer folders on a single hard-drive partition. Sounded like
trouble to me ;-)
Here, at work where I develop the app under discussion, I have only a G5 and
am unlikely to improve on that in the foreseeable future.
--
Mike McLaughlin
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden