parfor worker affinities

How much affinity is there usually in worker assignments using parfor?

In particular, suppose I have a program like the following:

parfor i = 1:N
   result1(i) = do_work_1(i);
end

% do stuff with result1 ...

parfor i = 1:N
   result2(i) = do_work_2(i);
end

Will do_work_2 be assigned to the same worker labs as do_work_1 most of the time? What if do_work_1 caches some partial results in core specific to iter i -- will do_work_2 benefit from this if it tries to rerun some of the same things, and what might be an expected sticky-assignment (i.e. cache hit) rate?

The following test program with a local matlabpool of size 8 gets only a 75% hit rate on average. Is there any way to improve that so it's more like 95%?

function hits = partest()
spmd
    set_labindex();
end
ntrials=100;
asgn = zeros(ntrials, 1000);
for trial = 1:ntrials
    parfor i = 1:1000
        asgn(trial, i) = get_labindex();
    end
end
hits = (asgn(2:end,:) == repmat(asgn(1,:), ntrials-1, 1));
end

function set_labindex()
global mylabindex;
mylabindex = labindex;
end

function mylabindex = get_labindex()
global mylabindex;
end

Thanks.

Answer 1

[Edric Ellis]

PARFOR is designed for order-independent loop iterations, and there's no way to control the placement of the iterates. If the "cached" data is not too large, you could return it from the PARFOR loop and then pass it back in again.

Alternatively, you could use SPMD and absolutely guarantee iteration placement. Something like this:

    spmd
        x = codistributed.zeros( 1, 20 );
        for ii = drange(1:20)
            x(ii) = rand();
        end
    end
    xg = gather(x);

See the for-drange in SPMD documentation for more details. Obviously, this isn't so straightforward to use as PARFOR, but that's the trade-off when you need to guarantee iteration placement.