Hacker News Reader

Comment by hinkley | Hacker News Reader

I remember a paper decades ago now about a way to reduce RPC call round-tripping by sending something akin to promises back and forth, so you could pass the result of one remote call to another one without transferring it across the network. Kinda think something similar might be useful here.

What typically ends up happening in “services” (or any distributed system) is that you start creating convenience APIs to speed things up that are mostly just combinations of other calls, and you stay with the ones that seem like they might be the most useful, so you don’t slam into combinatorics face first.

Given the amount of talk I’ve heard about system call overhead lately, it sounds like the magnitude of the delays is creeping up again (especially post-Meltdown).

View on HN

I don't know if this is what you were thinking of, but capnproto[0] does exactly that with a promise like interface.

Actually this may be the paper you were referencing, from the bottom of the capnproto page:

> Cap’n Proto’s RPC protocol is based heavily on CapTP[1], the distributed capability protocol used by the E programming language[2]. Lots of useful material for understanding capabilities can be found at those links.

[0] https://capnproto.org/rpc.html

[1] http://www.erights.org/elib/distrib/captp/index.html

[2] http://www.erights.org/index.html

Very interesting, but if memory serves, Microsoft had this idea maybe in ‘96. Though patent expiry-wise, the timing of cap’n proto might make a bit of sense.

E is from '97 and built on top of ideas implemented before that with extensions to Java; not sure of the date, but could easily predate '96.

Java was still pretty brand spanking new in ‘96. And RMI wasn’t inflicted on us until ‘97. But half the stuff we use was invented in the 70’s and explored in the 80’s anyway.

The classes in college that I have used the most by far are the series that covered logic and set theory, and the one on distributed computing. The latter does take some of the fun out of people rediscovering things though.

IIRC, Berkeley had an OS with swarm computing and process migration around ‘87. It wasn’t until 20 years later that the speed of disk vs networking had a similar imbalance again. And of course the mainframe guys must constantly think the rest of us are idiots.

Oh I know, I started programming in '92 or so.

The idea of creating a program and sending it across an abstraction boundary for execution to avoid the cost of continually navigating the abstraction boundary for each step in the program is reasonably trivial. It was an approach I used in my first job for optimizing access to data in serialized object heaps - rather than deserialize the whole session object heap for each web request (costly), I'd navigate the object graph in the binary blob, but this required following offsets, arrays etc. The idea of a 'data path' program for fetching data occurred almost immediately.

In the end a different approach using very short-lived objects which were little more than wrappers around offsets into the heap combined with type info turned out to be more usable, and with generational GC, was plenty fast too; the abstraction stack was thin, the main cost avoided was materializing a whole heap.

Everyone is doomed to gradually rediscover QNX while never reinventing it.

The extent to which computer programmers literally don't read anything about computing history or alternative systems is quite funny. I can't wait until, sometime in the next few years, someone announces they're "modernizing the cloud operating system" and "unlocking the synergies between microservices" or whatever by... reinventing MsgSend, which we all knew about 30 years ago at this point.

To save you some time and test my prediction powers: they'll get $50 million in funding and almost flop until they find a way to stick Linux inside of a virtual machine (so it can act like a glorified driver for you, for device compatibility, because it turns out burning cash on trying to replicate 10 million lines of drivers isn't smart). It will grow Docker compatibility at some point. 90% of the development will come from one group of ~6 people. Then they'll get bought out and the project will die overnight. The end.

I wish some day that I could be that nonsense person and Dunning Kreuger my way to mad money by using my powers of selling the past as the future.

Batching and pipelining calls is a quite common design in RPC, especially databases. Mongodb for example has a very easy to use aggregate([op1, op2, ...]) function which you use to build a pipeline of generic operations that all data flows through on the server side, eg input to op2 is the output of op1, and so on.

It doesn't allow any client logic between op1 and op2 if that's what you meant though?

> It doesn't allow any client logic between op1 and op2 if that's what you meant though?

Yeah that seems to be the trick doesn’t it? Is the next step beyond pipelining A) provide a way to run limited code on the server end or B), reformulate the API so that these situations don’t occur as readily.

Take a classic I/O pattern. Give me 5k of data from X, write all 5k out to Y. Except that’s not what actually happens. It tells you what it wrote and you have to do a conditional branch and arithmetic. I still recall feeling shocked and a little scandalized when I learned that these APIs worked like this. First, why didn’t you just do what I asked, and second, why am I the one held responsible for all of the bookkeeping when you are the one selectively following instructions?

I think one of the features of completion ports was a slightly better, “go do this and don’t bother coming back until you have”.

In a client server application I designed as part of a previous job we did exactly this.

An RPC call was a list of functions and arguments, and there was a special tag that could refer back to a previous return value in the same set of calls.

All calls in the same request was executed in the same transaction. Them main goal was to avoid usingddistributed transactions, but also helped reducing latency over slow connections.

I think my comment got lost because I can’t find it, but I said something like: maybe we need a formal macroassembler for IPC/RPC calls instead of running “code” directly in the kernel.

It looks like inventing GraphQL for kernel:

On the web: instead of combining results of several RESTful API calls on the client, send a GraphQL request and combine the REST call on the server.

On a host: instead of combining results of several syscalls in user-space, send a program to an in-kernel interpreter that would combine the syscalls kernel-side aka define a syscall such as readfile() on the fly.

Yeah I had that though while writing up my first follow up, but the compositing here is between multiple, small endpoints and GraphQL is subsetting one large endpoint.

Maybe you could model kernel calls as a single large subsystem that allows multiple questions, but GraphQL seems a lot less imperative that syscalls so I’m having trouble picturing how that would translate.

> I remember a paper decades ago now about a way to reduce RPC call round-tripping by sending something akin to promises back and forth, so you could pass the result of one remote call to another one without transferring it across the network. Kinda think something similar might be useful here.

Those shortcuts are generally about the ability to batch independent concurrent operations though e.g. instead of

    call(foo)
    call(bar)
    call(baz)

you can

    multicall(foo, bar, baz)

which goes from 3 sequential round-trips to 1, without increasing "instantaneous" server load as much as performing concurrent calls (promise-style) would.

Here this is more of a pipeline desire and the issue there is it requires some error handling and adaptation between the calls, as the various functions are not always compatible (you often can't feed the output of one as the input of the next).

In theory, the JVM could allow users to upload ‘arbitrary’ code, where the configuration of the JVM (custom class loader) enforces various restrictions as to want that ‘arbitrary‘ means.

I have never seen that implemented, though, possibly because of the experience with the increase in attack surface Java applets gave, or because it is hard to restrict memory and CPU usage of uploaded code.

I heard a presentation on Jini when it was young and this something they very much wanted to do, but I believe it got watered down to mostly sending code from the server to the client and not so much the other way around.

This is reminding me of a research hardware project from the same era where they took NUMA design about as far as you could go; they embedded simple (vector?) computing directly onto the RAM chips, so the code goes to the data instead of the other way around. One of their demos was splitting the screen up into cells and calculating pixels in parallel directly on the memory chips.

Reply on news.ycombinator.com