Groups


200 of 99+  



julia-users ›
Unexpected behaviour when running parallelized code on single worker
9 posts by 3 authors  



Nils Gudat 	

4/4/15


There's something weird happening in my recently parallelized code. When running it without adding some worker processes first, the results are completely off and after some investigation I found that this was due to assignment operations going wrong - results of computations were assigned to different Arrays than the intended ones. A small working example illustrating the point:

x1 = linspace(1, 3, 3)
x2 = linspace(1, 3, 3)
x3 = linspace(1, 3, 3)

function getresults(x1::Array, x2::Array, x3::Array)
  result1 = SharedArray(Float64, (3,3,3))
  result2 = similar(result1)
  result3 = similar(result1)
  
  @sync @parallel for a=1:3
    for b=1:3
      for c=1:3
        result1[a,b,c] = x1[a]*x2[b]*x3[c]
        result2[a,b,c] = sqrt(x1[a]*x2[b]*x3[c])
        result3[a,b,c] = (x1[a]*x2[b]*x3[c])^2
      end
    end
  end
  return sdata(result1), sdata(result2), sdata(result3)
end

(r1,r2,r3) = getresults(x1, x2, x3)

nprocs()==CPU_CORES || addprocs(CPU_CORES-1)
(r1_par,r2_par,r3_par) = getresults(x1, x2, x3)


When I run this on my system  (v0.3.6), the parallelized version works as intended, while running the code without adding workers first gives the expected results for r1 and r3, but r2 holds the same results as r3. The behaviour in my original problem was similar, the code returns three Arrays, but running it without additional workers those Arrays all return the same contents.

Is there something in the @sync or @parallel macros that causes this? How should a code be written to ensure that it works both with one and multiple cores?
 


Patrick O'Leary 	

4/4/15


Have you tried this with a normal Array instead of a SharedArray for the outputs? (There may or may not be other problems and/or bugs in Julia, but I do know that SharedArray is considered experimental.)
- show quoted text -
 


Nils Gudat 	

4/8/15


Hi Patrick, 

Sorry for the late reply (Easter and all that)! The problem with using Arrays in the code above is that they're not available for remote processes to write on, so I'd have to come up with a more complicated structure of passing computations and results around. The whole appeal of SharedArrays to me is that they make this unnecessary and therefore lend itself perfectly to facilitate easy parallelization of the kind of problems economists are often facing (basically filling large Arrays with the results of lots and lots of simple maximization problems). One way to get around both problems would be to initialize the Array as

nprocs() > 1 ? result1 = SharedArray(Float64, (3,3,3)) : result1 = Array(Float64, (3,3,3))

The main reason for my original post here was to see whether anyone could explain why SharedArrays behave in this way when used on one process and whether this was potentially a bug (or at least something that should be mentioned in the docs).
 


Patrick O'Leary 	

4/8/15


I understand *why* you're using them; the question is whether they're broken or not. One way to figure that out is to not use them and see if you still get the weird behavior.

(No worries on the response speed, this is your issue after all!)
- show quoted text -
 


Tim Holy 	

4/8/15

Re: [julia-users] Re: Unexpected behaviour when running parallelized code on single worker

Sounds like a bug, but I think what Patrick was trying to say is that it would 
help to test it with Arrays first just to make sure there's not some problem 
with your code. Assuming that it works for Arrays but not for SharedArrays, 
then you should probably file an issue. 

Best, 
--Tim 
- show quoted text -
 


Nils Gudat 	

4/8/15

Re: [julia-users] Re: Unexpected behaviour when running parallelized code on single worker

Apologies again for being a little slow (mentally now, not in terms of response time); by trying an Array you mean running the code in single-core mode and using an Array instead of a SharedArray? Running it in parallel with a regular Array (unsurprisingly) doesn't work. So I have:

Single core: initializing result* as Arrays works, initializing as SharedArrays gives unexpected result
Multi-core: initializing result* as Arrays returns empty Arrays, initializing as SharedArrays works

I'm still not sure whether this is a bug or the "intended" behaviour of SharedArrays, i.e. whether SharedArrays maybe just aren't meant to work in this situation when not using multiple processes. I'm a bit reluctant to file an issue simply because my understanding of the workings of SharedArray is limited, so I thought I'd ask for help here first.
 


Tim Holy 	

4/8/15

Re: [julia-users] Re: Unexpected behaviour when running parallelized code on single worker

In a sense, a SharedArray should act like an Array if you're using a single 
core. I'm not saying all methods have been implemented for them, but if the 
code runs then it certainly shouldn't give different answers. So I'd say this 
is a bug. 

So now that we know it's a bug, I'd urge you to file an issue. The advantage is 
that it's less likely to be forgotten than an email. If whoever digs into it 
(maybe me but not this week, maybe someone else) discovers there isn't really 
a problem after all, you can blame me :-). 

--Tim 
- show quoted text -
 


Patrick O'Leary 	

4/8/15

Re: [julia-users] Re: Unexpected behaviour when running parallelized code on single worker

Thank you Tim for explaining that more clearly. This morning's reply was ENOCOFFEE :D

Please do file an issue, Nils, and thanks for investigating further.
- show quoted text -
 


Patrick O'Leary 	

4/20/15

Re: [julia-users] Re: Unexpected behaviour when running parallelized code on single worker

If you didn't see, this is now fixed (by https://github.com/JuliaLang/julia/pull/10877). Thanks for the report!
- show quoted text -