Should we control/optimize communications in Julia?

[Sukera]

@EdTi

I’m incredibly confused by this example. To me, it seems like :

1. Process 2 has no identifier referencing to the matrix that was created on it. The only reference to this matrix is the Future on master process.
2. Process 2 sends that matrix to master process
3. Process 1 adds one to every entry of that matrix
4. The result lies in process 1, it doesn’t exist on process 2

That’s not what’s happening. The remotecall creates the matrix on process 2, as the second argument specifies:

  remotecall(f, id::Integer, args...; kwargs...) -> Future

  Call a function f asynchronously on the given arguments on the specified process. Return a Future.
  Keyword arguments, if any, are passed through to f.

So the matrix already lives on process 2.

Similarly, @spawnat 2 ... results in the remainder of the code to be executed on process 2, which fetches the result from itself (which should be fast).

Only fetch(s) then sends the result of s back to process 1.

@EdTi

Is it a virtual process, consisting in a high-level layer of references, that doesn’t perform useless communications, and allows us to not worry about it?

No, it’s a regular julia process, visible in e.g. top, just as its workers are.

@EdTi

To me, it seems that this code will scatter A to the workers twice, unless the master process has a high-level layer.

Indeed it will, but only because you specify the slicing to happen on the remote processes.

It should be noted that regular julia arrays always only live on the process they were created at - they are not the same as MPI arrays. You may want to use DistributedArrays.jl or a similar package for having worker-local slices abstracted as one global array.

In particular, the Distributed stdlib is not a julia equivalent of MPI. It’s more like the necessary glue to have worker processes to run code on in the first place. You may be interested in MPI.jl instead.