Are you absolutely sure that, in the part you are trying to parallelize, no computation depends on the results of a previous computation. If those two computations are moved from serial to parallel then there is no guarantee that the first is complete before the second happens on a different process. Subtle situations include using the values from cells in an array (other than the one you are about to update). Those other cells may or may not be updated if the update code is in another process.
On Monday, February 1, 2016 at 4:11:01 AM UTC+10, Christopher Alexander wrote: > > Is this something that would really only be solved by proper > multi-threading? > > On Saturday, January 30, 2016 at 12:49:50 PM UTC-5, Christopher Alexander > wrote: >> >> I can confirm that I do not see the seg fault issue in 0.5 (the latest >> master), but I am getting fundamentally different results when using the >> @sync @parallel construction. In essence, @sync @parallel is causing >> arrays of different values (compared to using a non-parallelized >> construction) to be built, which is causing an issue further along in my >> program. It is also much slower, so I am wondering if I my syntax is >> incorrect. >> >> Any input would be appreciated. You can see what is supposed to be >> generated by loading this script ( >> https://github.com/pazzo83/QuantJulia.jl/blob/master/swaption_test_code.jl) >> and calling main(). >> >> Thanks! >> >> On Saturday, January 30, 2016 at 4:48:51 AM UTC-5, Lutfullah Tomak wrote: >>> >>> There is this issue on on github >>> https://github.com/JuliaLang/julia/issues/14764 . I am no expert about >>> parallel computing but may be related. >>> >>> Regards >>> >>
