Newbie query re multithreading
Newbie query re multithreading
- Subject: Newbie query re multithreading
- From: "McLaughlin, Michael P." <email@hidden>
- Date: Tue, 18 Aug 2009 10:25:46 -0400
- Acceptlanguage: en-US
- Thread-topic: Newbie query re multithreading
I am converting a Carbon app to Cocoa (where I'm a newbie). The Carbon app
was multithreaded and heavily dependent on cblas and clapack. It worked
well and was fully twice as fast with 2 CPUs as with 1. However, the code
was becoming increasingly obsolete.
I now have a Cocoa [ObjectiveC++] version, also multithreaded, targeting
Leopard and with Garbage Collection required (Xcode 3.1.3). In place of
BLAS and LAPACK, I am now using the public-domain Eigen library, sacrificing
some speed for readability.
My (very embarrassing) problem is that this Cocoa app is monotonically
*slower* with increasing number of CPUs. I have tried 1, 2 and 4 CPUs,
creating k NSOperations for k CPUs and adding them to an NSOperationQueue.
Obviously, the question is where to look for the cause. My experience with
Instruments is quite limited. Also, in this app, each NSOperation is
identical, processing 1/k of the input data with identical functions (hence,
identical function names).
FWIW, my old Carbon app is 18x faster than my fastest Cocoa version (28 sec
vs. 9 min), partly due to Eigen, of course.
With Instruments, some of the results I see are
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.
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).
3) The compute-intensive function that was explicitly multithreaded takes
3.4% of the time with 1 CPU and 1.7% with 2 CPUs, bearing in mind that the
latter runtime is about 25% longer overall.
4) Even though Instruments (Sampler, CPU Monitor, Cocoa Events) is using
"separate by thread", it does not show separate threads for my k
NSOperations; it still collects function names together so I cannot tell one
NSOperation from another.
Can anyone suggest what I should try next? I was really hoping that
multithreading would speed things up (as it did in my Carbon version).
Thanks for any tips.
--
Mike McLaughlin
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden