undefined | Better HN

0 pointsadwn7y ago0 comments

> 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.

0 comments

1 comments · 1 top-level

p4bl07y 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-1... :).

j / k navigate · click thread line to collapse