> On 29 Sep 2016, at 10:05, Gerriet M. Denkmann <[email protected]> wrote:
>
>
>> On 29 Sep 2016, at 14:38, Quincey Morris
>> <[email protected]> wrote:
>>
>> On Sep 29, 2016, at 00:15 , Gerriet M. Denkmann <[email protected]> wrote:
>>>
>>> dispatch_apply( nbrOfThreads, queue, ^void(size_t idx)
>>>
>>> As my computer has just 8 CPUs, I thought that using nbrOfThreads > 8 would
>>> be silly: adding overhead without gaining anything.
>>>
>>> Turns out this is quite wrong. One function (called threadHappyFunction)
>>> works more than 10 times faster using nbrOfThreads = a few ten-thousand (as
>>> compared to nbrOfThreads = 8).
>>>
>>> This is nice, but I would like to know why can this happen.
>>
>> What makes you think “nbrOfThreads” represents a number of threads?
>
> 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.
There are mored shared resources than just execution units in your system (e.g.
memory bandwidth, or for non-linear accesses latency). Maybe one of your blocks
is bandwidth bound, while the other is compute bound? Your second function
might be memory bound (with lots of read-modify-write traffic). There are many
other factors (and the dispatch_apply man-page tells you that number of
invocations is very dependant on your block), such as caches or
hyper-threading. The performance counters in Instruments may be able to guide
you.
Daniel.
_______________________________________________
Cocoa-dev mailing list ([email protected])
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 [email protected]
