Avoiding repeated large input data transfers when running parallel/distributed jobs

I'm currently writing a particle-trajectory function using input calculated from another program. The program feeds me the coordinates and simulated E field values for each point of the mesh it generated, and I need to find the E field at arbitrary points so I'm using TriScatteredInterp to produce these values. Given the input mesh coords and values, TriScatteredInterp produces a variable/class(? not sure) F, which I can query at my arbitrary point by F(r) where r=[x0 y0 z0]. So far, so good. I have three of these "F"s I query Fx, Fy, and Fz (one for each component of the E field). I have to run these three queries thousands of times, so I figured I could speed up the calculation 3x by having separate parallel processes run Fx(r), Fy(r), and Fz(r) separately on different cores.

What I found was that using parfor to do this was much, much slower. It took me a couple minutes to figure out, but from what I can tell every time MATLAB reaches my parfor loop, it sends/copies the entirety of Fx Fy or Fz to the respective parallel worker so it can run the calculation on that core. This is a problem because each F is several hundred mb of memory, so the parfor loop ends up spending 99% of its time transferring memory to its parallel workers, slowing the entire process down significantly.

What I am wondering is this: is there a way to keep, say, Fx loaded in core 1 persistently, so the core can just run the calculation without having to repeatedly get Fx? The values of Fx/Fy/Fz are never changed. Is this a job for spmd (I'm still unfamiliar with the concept)? Thanks a lot in advance, this has been bugging me for several hours now

Answer 1

[Raymond Norris]

It would help to know what type F is (class or simple data type). In the simplest case, parfor will slice F if you are indexing over it. If you require the entire F set for each iteration (i.e. a broadcast variable), you might consider assigning F (now a temporary variable) within the parfor loop. The hit of assigning F in each iteration might overcome the speed hit of transferring it to lab.

You could also combine spmd and parfor (not one inside the other). Use spmd to call a setter function (assigning F) that then gets referenced in the parfor. The temporary variable or spmd solution are ideal if you don't need the F after the parfor, since the data will be on the workers.

If you have a piece of code to share, post it for us to look at.