I've been experimenting lately with multi-architecture distributed computing (ARM <---> x86_64) with frameworks such as dask, ray and although there were quirks in getting them running on ARM; I was able to make it work [1].
I was thinking of checking out Julia's distributed computing capabilities next, but their insistence on same OS, path etc. (last time I checked) didn't inspire confidence in me for my purpose.
Would Chapel be a good alternative for multi-architecture distributed computing? My goals are simple, to explore what it takes to distribute & compute something across different architectures in parallel.
Historically, Chapel had an effort to support mixed instruction sets within a single logical program, but this effort fell by the wayside due to the amount of effort required to maintain it, combined with the fact that it was virtually unused (most HPC programmers are using homogeneous nodes, or at least ones with compatible ISAs).
Chapel can still be used in multi-architecture distributed computing today, but by running a Chapel program per ISA and having them communicate through more traditional means (e.g., ZMQ).
Maybe but it wasn’t the last time I did it. The main issue at the tome was that the naive deployment model uses SSH to deploy the artifacts and setup the cluster. Maybe it’s possible to create a hybrid build and do it that way but I’ve not tried.
I've been experimenting lately with multi-architecture distributed computing (ARM <---> x86_64) with frameworks such as dask, ray and although there were quirks in getting them running on ARM; I was able to make it work [1].
I was thinking of checking out Julia's distributed computing capabilities next, but their insistence on same OS, path etc. (last time I checked) didn't inspire confidence in me for my purpose.
Would Chapel be a good alternative for multi-architecture distributed computing? My goals are simple, to explore what it takes to distribute & compute something across different architectures in parallel.
[1]https://gist.github.com/heavyinfo/aa0bf2feb02aedb3b38eef203b...