Tue Aug 6 10:52:20 EDT 2019
The distributed "commutation" issue : the solution is a common language
Basically, a lot of code is built out of envent chains that start
somewhere physical and end somewhere physical, but the intermediate
chain is just communicating code that can run anywhere.
Is there a good way to look at this problem such that it can be
abstracted? I.e. such that that intermediate code can really run
anywhere, or even better, such that it can run in the optimal place?
I.e. start/end are hard constraints, but the intermediate locations
are soft: based on compute and comm, there might be an optimal place.
One of the really awkward limitations here is the change of language
when moving code from one "place" to another. That might actually be
the most important real-world issue: heterogeneity.
Maybe find a single common language that can run anywhere? Once that
is in place, task migration should be straightforward. Compilation is
just cache (e.g. migration is expensive only if recompilation is
EDIT: The thing here is to make an actual model for it, and then just
describe ways in which the model cannot be implemented. I.e. first
describe the ideal, then in a second level, describe the holes.
There are a couple of "languages" or "machines". Both are needed,
because state is needed to be moved.
- Erlang processes
- Linux C processes
- uC firmware
- FPGA gateware
Possibly also Rust, but that is currently not really a requirement.