Re: NSOperation Efficiency
Re: NSOperation Efficiency
- Subject: Re: NSOperation Efficiency
- From: Quincey Morris <email@hidden>
- Date: Wed, 05 Dec 2012 00:13:34 -0800
On Dec 4, 2012, at 23:02 , "Gerriet M. Denkmann" <email@hidden> wrote:
> And got almost the same overhead (tested three times with 99 operations);
> clock time per operation expected time overhead factor
> // 8 ops 29.9, 30.1, 29.7 12.5 2.4
> // 7 ops 29.2, 30.0, 29.7 14.3 2.1
> // 6 ops 28.8, 28.5, 29.0 16.7 1.7
> // 5 ops 28.6, 28.4, 28.9 20 1.4
> // 4 ops 29.4, 31.9, 30.8 25 1.2
> // 3 ops 35.7, 35.4, 35.2 33 1.06
> // 2 ops 51.7, 51.5, 51.2 50 1.03
> // 1 ops 100
>
> Looks like NSOperationQueue has some problems, or?
Your expected times are questionable:
1. You "expect" a multi-threaded execution to have no measurable overheads at all. Since your expectations are unreasonable, you don't know whether the actual times are good or bad.
2. You don't state whether you create all of the operations before letting any run, or if you're creating them while some are already running. That's going to affect what you measure as overheads. The questions of overheads in queuing operations (which Kyle has being saying is inefficient) is an entirely separate matter from what you seem to be measuring here.
3. Even if you had all of the operations ready to start, there might be a different set of overheads in actually starting them, apart from creating them in the first place.
4. How many cores on the Mac you used for the test? 2? 4? 8?
5. Each core can support 2 threads via hyperthreading, but nothing guarantees that simultaneous threads in a single core are so completely parallel as to execute twice as fast as 2 threads in 2 different cores. In fact, it's almost certainly true that 2 threads in the same core run significantly slower, since they're competing for certain parts of the core's hardware.
6. How do you know that the cores are all running at the same clock speed throughout your tests? My understanding is that, in recent Intel CPUs at least, the fewer cores you use, the faster they go.
7. You don't know how OS X prioritizes thread switches in an extremely compute-bound scenario like this, as opposed to a mixed-use scenario where threads voluntarily give up their time slice pretty often.
8. You don't take into account what else might be using CPUs during your test.
9. Beyond a certain level of usage, OS X might be throttling your execution to ensure that it doesn't excessively hinder the "near-future" execution of other apps, or its own internal processes.
What I think you can take away from this test is that using more than 3 simultaneous threads doesn't really help reduced the *elapsed* time of the whole set of operations. On this Mac, therefore, you wouldn't want to allow more than 3, but of course the answer could be different on other Macs.
Perhaps the *important* test is to give control of the number of simultaneous operations back to NSOperationQueue. If that produces elapsed times of about 35, then you have some evidence that the default behavior is the correct choice.
_______________________________________________
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