-
-
Notifications
You must be signed in to change notification settings - Fork 200
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support SharedArrays #215
Comments
I think we just try to get SharedArrays fixed since the current behavior seems broken in many ways. If we need it right now, since it's a Base type we can add some special handling. What's the use case? |
I'm experimenting with parallelisation strategies for (hyperbolic) PDE discretisations. I've tried using threads and standard |
Shall I implement such a check in the initialisation part? |
If that fixes it, go for it. |
@dextorious found before (in a different case) that SharedArrays have quite a bit of overhead. I think the more interesting case is trying DistributedArrays and a strategy for having it automatically handle the operator's actions at the boundaries between processes. |
Sounds also interesting. I will write tests concerning the usage of both types of parallel arrays. I found a very strange behaviour of threads. I wanted to construct types with field Does this approach with |
You mean auto-parallelism here? I am not sure what you're asking. A user can always parallelize in their |
I have something like struct Semidiscretisation{OtherStuff, Parallel}
other_stuff::OtherStuff
parallel::Parallel
end
function (semidiscretisation::Semidiscretisation)(t, u, du)
foo!(du, u, t, semidiscretisation.other_stuff, semidiscretisation.parallel)
end where a serial version is used for |
Nah, that seems fine. Normally I think you can assume that operators will faster when threaded though, so DiffEqOperators.jl implicitly multithreads its |
Thanks for sharing your opinion.
That's what I thought. Additionally, threading prevents the normal error messages and makes debugging much more complicated if some errors occur. And it seems to be complicated to get all the performance from threading. |
This frequently gets in the way: JuliaLang/julia#15276 |
Yeah, that's it. It seems to be possible to use same(u::AbstractArray) = similar(u)
same(u::SharedArray) = typeof(u)(size(u)...) Then, we would have to use |
I think we should keep to
I think that's the real answer. An array type that multithreads broadcast. I thought GPUArrays' JLArray did that, but I guess not. We can go bug Simon to make it happen 👍. In general I don't think |
Okay, then I'll close this issue now. Thanks for your thoughts! |
SharedArray
s are currently not supportedI'm using julia
v0.6.1
This is due to the problem that
copy(::SharedArray)
andsimilar(::SharedArray)
do not returnSharedArray
sSee also JuliaLang/julia#12964, JuliaLang/julia#22218, https://discourse.julialang.org/t/why-does-similar-sharedarray-create-an-array/6673/3.
Shall we use
deepcopy
instead ofcopy
forSharedArray
s?The text was updated successfully, but these errors were encountered: