On Fri, Mar 13, 2009 at 4:38 AM, Marcel Weiher <marcel.wei...@gmail.com> wrote: > > On Mar 12, 2009, at 10:54 AM, Bill Bumgarner wrote: >> >> In the context of an application, such processing is likely to be on a >> secondary thread and there is likely to be synchronization of data between >> threads. >> The overhead of the write barrier (which is spin lock contention under >> the covers, most likely) will be somewhat offset by the vast decrease in the >> cost of moving objects between threads, for example. > > The synchronization overhead for moving progress updates across threads > every 10th of a second is negligible unless you're doing something very very > wrong.
I have to agree with Marcel on this. In fact, in such a scenario, I'm almost certainly going to be using OSAtomicEnqueue and OSAtomicDequeue. I'm willing to guarantee that this will outperform a call to objc_assign_strongCast by several orders of magnitude, so much so that it would actually be an incentive to turn off GC. It has the added advantage of never causing the background worker threads to block while waiting for a spin lock. Come to think of it, I'm not even sure how you could write a GC enabled multi-threaded app that uses one thread per CPU to split work up. All your background threads are going to come to a grinding halt as they serialize inside objc_assign_strongCast. >> Sure -- and if I were writing a Cocoa application to do exactly that, it >> would be doing all kinds of UI updates during the process to keep the user >> up to date on progress, give them a feel for whether the analysis is moving >> along in the correct direction, etc,etc,etc.... and all of that graphics >> related chatter is very likely going to far outweigh the CPU cycles consumed >> by the actual data processing bit. > > Not if you're doing it right. Again, I have to agree with Marcel on this. In fact I'd say, as a rough rule of thumb, if shark is telling you that you're spending more than 5% of your time doing UI updates, you're doing something wrong. If you have something that takes 5 minutes to process without any kind of UI updates, and your GUI versions interface updates now 'far outweigh the CPU cycles consumed' (>50%) relative to the data processing, you've now turned something that takes 5 minutes in to 10+ minutes. I can't say I understand why you think this is reasonable, or even the norm. _______________________________________________ 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
