[Scilab-users] ?= Re: ?= =?utf-8?q? parallel_run

[Arvid Rosén]

Hi,

I agree. The lack of a working solution for parallel computations is a problem on modern server type machines with many cores. We typically try to work around this by having scilab functions that generate scilab scripts that are executed by spawned headless scilab processes. Communication is achieved by writing and reading files.

Needless to say, this is not a great solution, and with scilab 6 it is starting to become unpractical as writing and reading hdf files is extremely slow compared to the scilab 5 file format.

Cheers,
Arvid


From: Scilab Users List <users-bounces at lists.scilab.org> on behalf of Antoine Monmayrant <antoine.monmayrant at laas.fr>
Reply to: Users mailing list for Scilab <users at lists.scilab.org>
Date: Tuesday, 24 September 2019 at 09:32
To: "users at lists.scilab.org" <users at lists.scilab.org>
Subject: Re: [Scilab-users] ?= Re: ?= =?utf-8?q? parallel_run



Le 23/09/2019 à 23:13, stephane.mottelet at utc.fr<mailto:stephane.mottelet at utc.fr> a écrit :

Hello Antoine,

Before judging that some code is just a "dirty hack" you should first get into the code and see hows things are written. The implementation in 5.5.2 was using OpenMP so I don't see anything dirty here. The implementation was unstable under OSX and Linux, and under Windows parallel_run was just making calls sequentially. So no "dirty hack" under Windows but just a shortcut. Octave does also the same with Matlatb's parfor : it just does things sequentially. However, even unstable, parallel_run was very useful (I used it a lot under Linux to do some Monte Carlo estimation on a 40 processor machine). It is a pity that it's re-engineering for 6.0 familiy was not a priority.

Hello Stephane,

I'm sorry, I did not want to sound rude calling it a "dirty hack".
It's just the explanation I got from scilab developers last time I discussed with them about it.
We were trying to get similar performances under linux/osx/windows with some code using parallel_run.
That was a dead end.

Having any sort of parallel computing under scilab 6.0.2 would be a real step forward for us.
I have played a bit with julia to see what it means parallelizing some code in julia.
It was quite easy.
I don't know whether a similar approach can be implemented in scilab.



Antoine

S.

Quoting Antoine Monmayrant <amonmayr at laas.fr<mailto:amonmayr at laas.fr>>:

Hello,

Are you using Windows or anything else?
Because as far as I remember, parallel_run is just a dirty hack that only works under windows.
On my linux install of scilab 6.0.2, I also have:
--> parallel_run

Undefined variable: parallel_run

So it might be a bug in the documentation that should mention "windows only" like some other functions.

Antoine


Le Lundi, Septembre 23, 2019 15:46 CEST, fujimoto2005 <fujimoto2005 at gmail.com<mailto:fujimoto2005 at gmail.com>> a écrit:

I wanted to use "parallel_run" and tried the sample script in the help page.
But it did not work with the error message "undefined
variable:parallel_run".
Please teach me what is wrong?

The sample script I used is as follows
******
for i = 1:10
  res(i) = i*i;
end;
// for parallel_run, we need to have a function performing the computation
function a=g(arg1)
  a=arg1*arg1
endfunction

res = parallel_run(1:10, g);
// => res = [1  4  9  16  25  36  49  64  81  100];
*********





--
Sent from: https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/mailinglists.scilab.org/Scilab-users-Mailing-Lists-Archives-f2602246.html
_______________________________________________
users mailing list
users at lists.scilab.org<mailto:users at lists.scilab.org>
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users
_______________________________________________
users mailing list
users at lists.scilab<mailto:users at lists.scilab>.orghttps://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users





_______________________________________________

users mailing list

users at lists.scilab.org<mailto:users at lists.scilab.org>

http://lists.scilab.org/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20190924/e048c851/attachment.htm>