3 ms·

There's an exception to this rule if the underlying network does not go wrong. In particular, if the "network" is something local to one machine, pcie or some

There's an exception to this rule if the underlying network does not go wrong. In particular, if the "network" is something local to one machine, pcie or some cross-chip fabric thing, where the failure modes of the "network" are the box falls over, then RPC works as one might hope. You don't have to mangle functions to take account of extra network errors because there are none. The specific use case I'm interested in is heterogenous compute on shared memory machines. Code running on a GPU can call `int rc = fprintf(stderr, "oh dear");` and have no idea whether that runs code on a CPU or not. Code running on a CPU can call some linear algebra function and either run it locally or on a GPU, unobservable to the caller. That is a good trick. It does make for an interesting debugging experience where you lose track of where code is executing. ---- There's a less esoteric application in the area of the OP for pure functions where you don't need the result immediately. That goes something like: 1. Call the function and get back a promise or similar. All runs locally, no failures 2. Something in the background maybe does the work for you 3. Ask for the result. If it's not available yet, do the work locally That has the same zero failure modes property because it'll ultimately run all the work locally if the network offloading never works out. It only really makes sense if the functions can be called multiple times (e.g. locally and remote at the same time) without doing harm, i.e. pure functions. It costs latency and gains throughput. For some batch computation work that is great.

ColonelPhantom 3y ago
Won't the proposed implementation risk doing duplicate work? e.g. another machine starts on your work, but then you ask for it before it's done. So you'd probably need the "not available, but already 'stolen' case". For example, the current machine could look for work to steal itself. But this probably will increase latency a lot, so it would only make sense if the batches are huge.
- lunarcave 3y ago
  It's really hard to have exactly-once delivery[1]. But exactly once processing is viable. With Differential, the implementation does allow for idempotency in cases where you need exactly-once processing. And it does handle the "not available, but already 'stolen' case". Disclaimer: I'm an author. [1] https://news.ycombinator.com/item?id=34986691 https://news.ycombinator.com/item?id=34986691
- JonChesterfield 3y ago
  The sketch above makes duplicated work and inefficiency very likely. It's explicitly choosing at-least-once execution. The problem with the "already scheduled" pattern is when the machine holding the task falls over. Not a good choice for bank transactions. A good option for something like a distributed build farm - it doesn't matter hugely if you compile some piece of program repeatedly, but it matters a lot if you send the only copy of some source to a machine that immediately goes offline. Mainly bringing it up as a case in which RPC works beautifully - remote machine failures can be completely hidden by a willingness to do the work locally instead.
charcircuit 3y ago
>There's an exception to this rule if the underlying network does not go wrong. There is another big restriction. The sender and receiver have to be in the same process. Else it's possible that the receiver does not exist and there is no way to start the receiver back up.
valenterry 3y ago
> There's an exception to this rule if the underlying network does not go wrong. Fair enough. Maybe we shouldn't call it remote procedure calls then, because it's not remote anymore. The word remote exists to make the distinction compared to local. If there is no distinction in a given context, there is no need to use that word from the beginning.
- JonChesterfield 3y ago
  Maybe? Say one processor is an aarch64 core and another is x64, but someone has put them on the same memory subsystem and the system as a whole tends to die if either falls over. And then you want to make a function call from one to the other - it isn't as remote as another machine, but you can't pass things in registers either. "Remote" call seems a reasonable description to use for that but as the semantics are indeed different perhaps a new term should be used.

ColonelPhantom 3y ago

Won't the proposed implementation risk doing duplicate work? e.g. another machine starts on your work, but then you ask for it before it's done. So you'd probably need the "not available, but already 'stolen' case". For example, the current machine could look for work to steal itself. But this probably will increase latency a lot, so it would only make sense if the batches are huge.

lunarcave 3y ago
It's really hard to have exactly-once delivery[1]. But exactly once processing is viable. With Differential, the implementation does allow for idempotency in cases where you need exactly-once processing. And it does handle the "not available, but already 'stolen' case". Disclaimer: I'm an author. [1] https://news.ycombinator.com/item?id=34986691 https://news.ycombinator.com/item?id=34986691
JonChesterfield 3y ago
The sketch above makes duplicated work and inefficiency very likely. It's explicitly choosing at-least-once execution. The problem with the "already scheduled" pattern is when the machine holding the task falls over. Not a good choice for bank transactions. A good option for something like a distributed build farm - it doesn't matter hugely if you compile some piece of program repeatedly, but it matters a lot if you send the only copy of some source to a machine that immediately goes offline. Mainly bringing it up as a case in which RPC works beautifully - remote machine failures can be completely hidden by a willingness to do the work locally instead.

charcircuit 3y ago

>There's an exception to this rule if the underlying network does not go wrong. There is another big restriction. The sender and receiver have to be in the same process. Else it's possible that the receiver does not exist and there is no way to start the receiver back up.

valenterry 3y ago

> There's an exception to this rule if the underlying network does not go wrong. Fair enough. Maybe we shouldn't call it remote procedure calls then, because it's not remote anymore. The word remote exists to make the distinction compared to local. If there is no distinction in a given context, there is no need to use that word from the beginning.

JonChesterfield 3y ago
Maybe? Say one processor is an aarch64 core and another is x64, but someone has put them on the same memory subsystem and the system as a whole tends to die if either falls over. And then you want to make a function call from one to the other - it isn't as remote as another machine, but you can't pass things in registers either. "Remote" call seems a reasonable description to use for that but as the semantics are indeed different perhaps a new term should be used.