3 ms·

> One of my professors had an idea about distributed synchronous programming, but nothing ever came of it. It shouldn't be too difficult to distribute synchron

by p4bl0 8y ago

> One of my professors had an idea about distributed synchronous programming, but nothing ever came of it. It shouldn't be too difficult to distribute synchronous languages, and it is a quite natural idea. Most have a semantics based on Kahn networks [1], which is already a distributed model of computation :). [1] https://en.wikipedia.org/wiki/Kahn_process_networks https://en.wikipedia.org/wiki/Kahn_process_networks

adwn 8y ago
> It shouldn't be too difficult to distribute synchronous languages, and it is a quite natural idea. Most have a semantics based on Kahn networks [1], which is already a distributed model of computation :). I don't think this is correct. Kahn networks are asynchronous (and therefore well-suited for distributed systems), but synchronous languages are – well, synchronous. For every pair of nodes that exchange information, there has to be a rendezvous between them after every non-instantaneous step [1], which is terrible for performance in a distributed system (but virtually free in typical single-clocked, synchronous digital circuits). [1] You can devise heuristics which reduce the frequency of those rendezvous in some cases, but conceptually, they're still there.
- p4bl0 8y ago
  Mh, you're right. However, there is a notion of synchronous Kahn networks, but maybe it is only used by functional synchronous and dataflow languages (e.g., Lucid Synchrone, ReactiveML). Compilation of such languages involve clock calculus (i.e. typing for scheduling) which I think makes it possible to compute the maximum size of a queue in the network (or maybe at least guarantee that the size is bounded?). This would mean that what you call rendezvous points would be statically computable (in the case of pure synchronous languages it should be easy as the maximum queue size is zero, or one depending on how we count). Anyway, you're right that I was mistaken to think that it was an easy problem. EDIT: Heh: https://www.lri.fr/~mandel/papiers/MandelPlateauPouzet-MPC-10.pdf https://www.lri.fr/~mandel/papiers/MandelPlateauPouzet-MPC-1... :).

by p4bl0 8y ago

adwn 8y ago

> It shouldn't be too difficult to distribute synchronous languages, and it is a quite natural idea. Most have a semantics based on Kahn networks [1], which is already a distributed model of computation :). I don't think this is correct. Kahn networks are asynchronous (and therefore well-suited for distributed systems), but synchronous languages are – well, synchronous. For every pair of nodes that exchange information, there has to be a rendezvous between them after every non-instantaneous step [1], which is terrible for performance in a distributed system (but virtually free in typical single-clocked, synchronous digital circuits). [1] You can devise heuristics which reduce the frequency of those rendezvous in some cases, but conceptually, they're still there.

p4bl0 8y ago
Mh, you're right. However, there is a notion of synchronous Kahn networks, but maybe it is only used by functional synchronous and dataflow languages (e.g., Lucid Synchrone, ReactiveML). Compilation of such languages involve clock calculus (i.e. typing for scheduling) which I think makes it possible to compute the maximum size of a queue in the network (or maybe at least guarantee that the size is bounded?). This would mean that what you call rendezvous points would be statically computable (in the case of pure synchronous languages it should be easy as the maximum queue size is zero, or one depending on how we count). Anyway, you're right that I was mistaken to think that it was an easy problem. EDIT: Heh: https://www.lri.fr/~mandel/papiers/MandelPlateauPouzet-MPC-10.pdf https://www.lri.fr/~mandel/papiers/MandelPlateauPouzet-MPC-1... :).