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

[Stéphane Mottelet]

Le 24/09/2019 à 09:29, Antoine Monmayrant a écrit :
>
>
> Le 23/09/2019 à 23:13, 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.
>
Under OSX parallel_run used to work (a little bit) up to 5.5.1 version, 
then it was almost unusable.
>
> 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.
>
Yeah, Julia has many interesting features but things have been 
developped with such a kind of orthodoxy that using it is sometimes very 
baffling...
>
> I don't know whether a similar approach can be implemented in scilab.
>
The rewritten internals (ast module) would allow to implement (at least) 
something similar to Matlab's parfor. parallel_run worked by forking the 
main Scilab process, that's why it was not transposable to Windows (no 
fork()). Maybe could it be possible with threads with the new 
architecture ? The only thing that's certain is that without an active 
collaboration of Antoine Elias this feature will never be developped. 
The only way is to persuade ESI that it is a strategic feature for their 
business with Scilab !

S.

>
> 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 
>>>> <https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/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 
>>>> <https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/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
>> http://lists.scilab.org/mailman/listinfo/users
>
> _______________________________________________
> users mailing list
> users at lists.scilab.org
> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users

-- 
Stéphane Mottelet
Ingénieur de recherche
EA 4297 Transformations Intégrées de la Matière Renouvelable
Département Génie des Procédés Industriels
Sorbonne Universités - Université de Technologie de Compiègne
CS 60319, 60203 Compiègne cedex
Tel : +33(0)344234688
http://www.utc.fr/~mottelet

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20190924/9384ef83/attachment.htm>