[Scilab-users] parallel_run mixed with vectorization

Stéphane Mottelet stephane.mottelet at utc.fr
Tue Jun 14 15:44:38 CEST 2016


Hello,

IMHO parallel_run is very unstable and should be considered as an 
experimental feature.  I never managed to make it work with multiple 
arguments. The workaround is the following :

function U=fct(i)
     U1 = R1(i) * i1(i);
     U2 = R2(i) * i2(i);
     U = [U1 U2]';
endfunction

n = 1000;

// les vecteurs doivent etre en ligne pour la parallelisation

i1 = grand(1,n,'unf',0,0.1);
R1 = grand(1,n,'unf',0,500);
i2 = grand(1,n,'unf',0,0.1);
R2 = grand(1,n,'unf',0,1000);

// using parallel_run

Result = zeros(2,n); // au final, on a une matrice de dim (2xn)
tic()
Result = parallel_run(1:n, fct,[2,1]); // pour les n calculs, on sont un 
vecteur de dim (2x1) = meme dimension que U en sortie
disp(Result);
time = toc(); printf("time = %g\n",time);

The "1:n" trick allows to use any kind of data type, but be aware that 
the mechanism of parallel_run is based on subprocess (not threads) hence 
Scilab and its actual main workspace is cloned as many times as the 
number of cores. This is not a problem if you have a lot of memory...

However, I don't fully understand what you meant by mixing parallel_run 
and vectorization. Your original script did

Result = parallel_run([R1,i1,R2,i2], fct,[2,1]);

which should be (without the brackets)

Result = parallel_run(R1,i1,R2,i2, fct,[2,1]);

however, this syntax leads to a Scilab freeze (with 100% CPU on all 
cores) : it should be ok but as I already said parallel_run is quite 
buggy...

Moreover the ".*" instead of "*" was not useful since fct() is called 
with scalar arguments.

S.

Le 14/06/2016 à 14:31, Carrico, Paul a écrit :
>
> Hi again
>
> In the following new example, there’s something I do not caught ; I 
> cannot figure out what I’m misunderstanding
>
> Am I right to say that n calculations are splitted on the available 
> processors?
>
> Paul
>
> ################################################################”
>
> mode(0);
>
> stacksize('max');
>
> clear;
>
> function*U*=_fct_(*R1*, *i1*, *R2*, *i2*)
>
> U1 = *R1*. * *i1*;
>
> U2 = *R2*. * *i2*;
>
> *U* = [U1 U2]'; /// matrice (2x1) a chaque iteration  apres tansposition /
>
> clearU1; clear U2;
>
> endfunction
>
> n= 1000;
>
> /// les vecteurs doivent etre en ligne pour la parallelisation/
>
> i1= grand(1,n,'unf',0,0.1);
>
> R1= grand(1,n,'unf',0,500);
>
> i2= grand(1,n,'unf',0,0.1);
>
> R2= grand(1,n,'unf',0,1000);
>
> /// using parallel_run/
>
> Result= zeros(2,n); /// au final, on a une matrice de dim (2xn)/
>
> _tic_()
>
> Result= parallel_run([R1,i1,R2,i2], _fct_,[2,1]); /// pour les n 
> calculs, on sont un vecteur de dim (2x1) = meme dimension que U en sortie/
>
> disp(Result);
>
> time= _toc_(); printf("time = %g\n",time);
>
> */EXPORT CONTROL :
> /**Cet email ne contient pas de données techniques
> This email does not contain technical data*
>
>
>
> _______________________________________________
> users mailing list
> users at lists.scilab.org
> http://lists.scilab.org/mailman/listinfo/users


-- 
Département de Génie Informatique
EA 4297 Transformations Intégrées de la Matière Renouvelable
Université de Technologie de Compiègne -  CS 60319
60203 Compiègne cedex

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20160614/22156fc5/attachment.htm>


More information about the users mailing list