Re: Mystery Threads

2016-10-01 Thread Gerriet M. Denkmann
> On 1 Oct 2016, at 01:33, Quincey Morris > wrote: > > On Sep 30, 2016, at 02:57 , Gerriet M. Denkmann wrote: > >> Any ideas where to look for a reason? > > The next step is probably to clarify the times between: > > a. Accumulated

Re: Mystery Threads

2016-09-30 Thread Quincey Morris
On Sep 30, 2016, at 02:57 , Gerriet M. Denkmann wrote: > > dispatch_apply(8,…): > My function is running 3090 msec and blocked 970 ms. > And with dispatch_apply(20,000,…): > My function is running 196 msec and blocked 27 ms. In a way, this is good news, because a difference

Re: Mystery Threads

2016-09-30 Thread Jonathan Mitchell
> On 30 Sep 2016, at 10:57, Gerriet M. Denkmann wrote: > > > > But I just cannot see anything which forces my function to run 16 times > longer in the first case. > > Any ideas where to look for a reason?

Re: Mystery Threads

2016-09-30 Thread Gerriet M. Denkmann
> On 29 Sep 2016, at 16:05, Roland King wrote: > > >> On 29 Sep 2016, at 16:59, Gerriet M. Denkmann wrote: >> >> >>> On 29 Sep 2016, at 15:34, Quincey Morris >>> wrote: >>> >> >> Well, I count this as (bigArea = 4

Re: Mystery Threads

2016-09-29 Thread Roland King
> On 29 Sep 2016, at 16:59, Gerriet M. Denkmann wrote: > > >> On 29 Sep 2016, at 15:34, Quincey Morris >> wrote: >> >> On Sep 29, 2016, at 01:05 , Gerriet M. Denkmann wrote: >>> >>> Well, nothing. Just let’s call

Re: Mystery Threads

2016-09-29 Thread Gerriet M. Denkmann
> On 29 Sep 2016, at 15:34, Quincey Morris > wrote: > > On Sep 29, 2016, at 01:05 , Gerriet M. Denkmann wrote: >> >> Well, nothing. Just let’s call it nbrOfBlocksToBeUsedByDispatchApply, or >> whatever. But ultimately any of these

Re: Mystery Threads

2016-09-29 Thread Daniel Vollmer
> On 29 Sep 2016, at 10:05, Gerriet M. Denkmann wrote: > > >> On 29 Sep 2016, at 14:38, Quincey Morris >> wrote: >> >> On Sep 29, 2016, at 00:15 , Gerriet M. Denkmann wrote: >>> >>> dispatch_apply(

Re: Mystery Threads

2016-09-29 Thread Quincey Morris
On Sep 29, 2016, at 01:05 , Gerriet M. Denkmann 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

Re: Mystery Threads

2016-09-29 Thread Gerriet M. Denkmann
> On 29 Sep 2016, at 14:38, Quincey Morris > wrote: > > On Sep 29, 2016, at 00:15 , Gerriet M. Denkmann wrote: >> >> dispatch_apply( nbrOfThreads, queue, ^void(size_t idx) >> >> As my computer has just 8 CPUs, I thought that using

Re: Mystery Threads

2016-09-29 Thread Quincey Morris
On Sep 29, 2016, at 00:15 , Gerriet M. Denkmann 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

Re: Mystery Threads

2016-09-29 Thread Aandi Inston
My thoughts are general, not specific to Mac OS... The idea that the best performance comes from threads = #CPUs is attractive, but will work only if the threads do not sleep and do not interfere with each other. A classic example is dividing up a complex calculation that runs without touching the

Mystery Threads

2016-09-29 Thread Gerriet M. Denkmann
I have a big array (like a few GB) which is operated upon by some functions. As these functions act purely local, an obvious idea is: - (void)someFunction { nbrOfThreads = ... sizeOfBigArray = ... a few GB stride = sizeOfBigArray / nbrOfThreads