From what you wrote, I would say there is serious load imbalance in the loop. "Half time inside the windows Sleep function" actually means workers did not succeed in finding job to steal (Sleep(0) is called to yield CPU time if several attempts to steal some job had no result). Might it happen that in reality 90+ % of the time is spend for processing 1-5 elements andnot evenly distributed across 145?

There are two things I would do:

• Use the technique described by Kevin in this blog post, to better understand workload characteristics


• Do not use auto_partitioner and try grainsize of 1. According to your data (relatively small # of iterations and relatively large time), the ratio of computation to iteration overhead should be big enough to justify this grainsize; and it gives best possible balancing. You might try to increase grainsize later if required.

Using these two options together, you might get the exact time spend at each iteration. Given the number of iterations, it is feasible to obtain, and analyze load balancing then.

I think your problem is that you don't really have any CPU to divide and conquer. Having a single core with hyper threading is not the same as having 2 cores. In fact, I would have predicted that your perf would be worse than that just using a single thread. You are essentially telling the system to divide and conquer the work, but you really only have one compute resource to execute. Thus, all you have done is add work to what you are tring to do, i.e. instead of just computing, you are computing and trying to divide the work.

Get a new computer with 2 or 4 cores and you will see some real performance gains.

/JMB

You might also take a look at my blog entries on analyzing TBB pipeline performance using Intel Thread Profiler and ITT event notifications, which is a great way to look at load balance issues, although I suspect JMB may have hit the right note. Hyper-Threading is a win when you have a mix of operations and can more fully utilize the functional units in the CPU by splitting it between a pair of threads, but if you're just pounding on specific units--like doing lots of floating point--you can saturate the out-of-order engine with justa single Hyper-Thread. Adding a second thread just adds more overhead. But first I would recommend you try Alexey's suggestion regarding grain size.