Re: Mystery Threads
Re: Mystery Threads
- Subject: Re: Mystery Threads
- From: Roland King <email@hidden>
- Date: Thu, 29 Sep 2016 17:05:28 +0800
> On 29 Sep 2016, at 16:59, Gerriet M. Denkmann <email@hidden> wrote:
>
>
>> On 29 Sep 2016, at 15:34, Quincey Morris <email@hidden> wrote:
>>
>> On Sep 29, 2016, at 01:05 , Gerriet M. Denkmann <email@hidden> wrote:
>>>
>>> Well, nothing. Just let’s call it nbrOfBlocksToBeUsedByDispatchApply, or whatever. But ultimately any of these things has to run on a CPU, of which there are no more than 8.
>>
>> Well, here’s my narrative. It may be fiction or non-fiction.
>>
>> You said you tried “nbrOf…” as a few ten-thousands, vs. 8. Let’s be concrete and call this (a) 40,000 vs. (b) 8. So, for each set of 40,000 iterations of your block, you’re doing 1 dispatch_apply in case #a, and 5,000 dispatch_apply calls in case #b. So, you’ve established that 4,999 dispatch_apply calls — and related per-dispatch_appy overhead — take a long time.
>
> Well, I count this as (bigArea = 4 GB):
> (a) one call of dispatch_appy which schedules 40 000 times a block to GCD which handles 0.1 MB
> (b) one call of dispatch_appy which schedules 8 times a block to GCD which handles 500 MB
>
> Could be that these blocks sometimes collide (maybe when they are operating on adjacent areas), which slows them down. Such a collision is rather unlikely if only 8 of 40 000 are running.
>
>
>> Of course, I’m relying on the fact that you’re doing the same number of *total* iterations of your inner loop in case #a and case #b. This is not quite the whole story, because there are loop setup overheads per block. However, the loop setup that you’ve shown is very simple — a couple of Int operations — so the additional 4,999 loop setup executions are likely dwarfed by 4,999 dispatch_apply executions.
>
> The actual story is: one outer loop (same in all cases) which sets up some parameters, then another loop which covers the area which is assigned to this block.
> In case (a) this area is small: 0.1 MB, whereas in case (b) it is large: 500 MB. Which seems to be in favour of case (b).
>
>
Why guess - this is exactly what Instruments is designed to tell you. It’s even dispatch-aware so it can show you results broken down by dispatch queue and worker thread inside the dispatch queue. Run the two under instruments and find out where all the time is spent.
_______________________________________________
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