> On 29 Sep 2016, at 16:59, Gerriet M. Denkmann <g...@mdenkmann.de> wrote: > > >> On 29 Sep 2016, at 15:34, Quincey Morris >> <quinceymor...@rivergatesoftware.com> wrote: >> >> On Sep 29, 2016, at 01:05 , Gerriet M. Denkmann <g...@mdenkmann.de> 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 (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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
