• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Mystery Threads
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Mystery Threads


  • Subject: Re: Mystery Threads
  • From: "Gerriet M. Denkmann" <email@hidden>
  • Date: Thu, 29 Sep 2016 15:59:18 +0700

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


Kind regards,

Gerriet.


_______________________________________________

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


  • Follow-Ups:
    • Re: Mystery Threads
      • From: Roland King <email@hidden>
References: 
 >Mystery Threads (From: "Gerriet M. Denkmann" <email@hidden>)
 >Re: Mystery Threads (From: Quincey Morris <email@hidden>)
 >Re: Mystery Threads (From: "Gerriet M. Denkmann" <email@hidden>)
 >Re: Mystery Threads (From: Quincey Morris <email@hidden>)

  • Prev by Date: Re: Mystery Threads
  • Next by Date: Re: Mystery Threads
  • Previous by thread: Re: Mystery Threads
  • Next by thread: Re: Mystery Threads
  • Index(es):
    • Date
    • Thread