However, I have tried to use it in my code in the following way and it resulted in an increase of the simulation running time compared to the non-parallelized version of the code.
I am dealing with large arrays and data files and have to calculate some statistics for a very large number of different cases.
In the initial non-parallelized version of my code, I calculate the statistics for case 1 to case 10^7 inside a for loop.
... "read many files"
... "generate large arrays"
... "Calculate statistics"
... "Write statistics in a text file"
In the parallelized version of the code, I use a PARFOR loop. However, I cannot have all the codes to calculate the statistics directly inside the PARFOR loop due to Matlab restrictions and errors. So, I had to create a new function called STAT and copy all the codes to calculate the statistics in this function.
The problem with my parallelized version of the code is that it takes much longer than the non-parallelized version. Inside the PARFOR loop, I have to call a function (STAT) and pass many large arrays (w1.Value) at each iteration.
Does anyone know what is the best way to optimize/parallelize this code?
Hi Matt, calling "clear" inside SPMD is not necessary - that's not the problem. Because of the way Composites work, when they go out of scope the workers don't find out immediately, only on the next SPMD block. If you add an SPMD block to your function, that's not sufficient since that happens before the Composites are created during the WorkerObjWrapper deletion.
Next suggestion: try adding the following line
val = ; dtor = ; valdtor = ;
as the last line inside the SPMD block in workerDelete.
30 Oct 2013
Worker Object Wrapper
Simplifies managing resources such as large data within PARFOR loops and SPMD blocks