freqanalysis: use parfor instead of for #2097
Conversation
move fixed-result out of the loop move only-once inside the main if itrial==1 check
To prepare for doing it out of the loop, to enable making the loop a parfor instead of for.
Instead of looking at the call stack, and expecting ft_freqanalysis at a specific position, have an explicit option in the specest functions on whether ft_progress can be used.
The variables acttimboind and acttboi have (for quite some time now) the same content, so no need to calculate twice
To prepare for using parfor for the main loop, need to have a different loop for each keeprpt option, because the outputs are asssigned to differently, which is not allowed within a parfor loop.
Setting this limit to 0 will make the execution non-parallel
|
Hi @AljenU, Following this, can you change the branch for this pull request following this documentation. It should point to the parallel branch, which ar this moment is still in perfect sync with the master branch. And can you do the same for PR #2068 and #2069 ? I will then merge them all. thanks, |
@robertoostenveld Done |
|
thanks! |
|
There are still a few things on https://github.com/fieldtrip/fieldtrip/projects/5 to be done by us (i.e. @schoffelen and me), mainly regarding documentation and updating the README on the parallel branch. |
For this function, using parfor does appear to be useful. The timing information gathered on some testfunctions does show improvement (#1853 (comment)), and this is also confirmed by the profiling reports.
This function also shows that sometimes, quite some work is needed to enable changing a for loop to a parfor loop.
Note that for now only the keeprpt cases 1 and 2 have a parfor loop, the case 4 is still a regular for loop. This because the case 4 indexes into the output in a way that is not compatible with parfor. Refactoring that case to use parfor could also be done, but it would use a lot more temporary memory.