On Sun, Mar 8, 2009 at 10:09 AM, Søren Hauberg <so...@hauberg.org> wrote:
> fre, 27 02 2009 kl. 14:03 +0100, skrev Jaroslav Hajek:
>> in case anyone is interested, I committed today into the "general"
>> package an initial m-file implementation of parcellfun.
>> parcellfun is supposed to be able to evaluate a given function for
>> multiple sets of input arguments using multiple processes.
>
> Just out of curiosity: would the same approach be a feasible way of
> implementing parallel for-loops? It would be really nice to be able to
> do something like
>
> parfor k = 1:100
> do_stuff (k);
> endparfor
>
> where 100 processes would be forked.
>
> Søren
>
>
In principle, yes. This particular case is easily doable with
parcellfun; in fact, "parcellfun" corresponds to a loop with a
single-index non-local assignment, such as:
parfor k = 1:100
...
[a{k}, b{k}] = ...
endparfor
which is readily transformed to
loop_body = @(k) ...
[a,b] = parcellfun (@loop_body, cell2mat (1:100))
The question is what to do with more complicated bodies like
a{k,k+1} = ...
b(k,:) =
Ultimately, the body needs to be somehow transformed to the parcellfun
form and the results distributed afterwards.
The reason is that the processes don't actually share writable memory;
results are sent back via pipes.
So, a "parfor" implementation would need to analyze the body and
extract the left-hand sides of all assignements.
I think that by far the most cases can be easily handled by parcellfun
(especially assisted by anonymous functions) and those that can not
(such as complicated copying data around) are probably not suitable
for multi-processing anyway (the overhead of sending a job's result
through the pipe should be negligible compared to the job itself,
otherwise parcellfun is useless).
Right now I have no intention of getting beyond parcellfun and maybe
pararrayfun (which will likely be just a wrapper for the former). I
think that a serious efficient parallel loop construct aka OpenMP
would really need thread safety, and not just in liboctave, but in the
interpreter as well, and I don't think that is realistic in near
future (think of the symbol table, file table, error handling, etc)
regards
--
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz
------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Octave-dev mailing list
Octave-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/octave-dev
