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.

In general, tons of allocations/deallocations will limit the scalability of an application, regardless of GC or non-. There are locks along the malloc() code paths, for example.

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.

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.

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.


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.

Sounds like you have locks or synchronization points along the various code paths that are effectively making your multi-threaded app perform worse than single threaded. A common problem.

The key is to eliminate all points of synchronization that you can along the performance critical code paths.

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).

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.

b.bum

_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to