cannam@147: --- cannam@147: layout: post cannam@147: title: "Promise Pipelining and Dependent Calls: Cap'n Proto vs. Thrift vs. Ice" cannam@147: author: kentonv cannam@147: --- cannam@147: cannam@147: _UPDATED: Added Thrift to the comparison._ cannam@147: cannam@147: So, I totally botched the 0.4 release announcement yesterday. I was excited about promise cannam@147: pipelining, but I wasn't sure how to describe it in headline form. I decided to be a bit cannam@147: silly and call it "time travel", tongue-in-cheek. My hope was that people would then be cannam@147: curious, read the docs, find out that this is actually a really cool feature, and start doing cannam@147: stuff with it. cannam@147: cannam@147: Unfortunately, [my post](2013-12-12-capnproto-0.4-time-travel.html) only contained a link to cannam@147: the full explanation and then confusingly followed the "time travel" section with a separate section cannam@147: describing the fact that I had implemented a promise API in C++. Half the readers clicked through cannam@147: to the documentation and understood. The other half thought I was claiming that promises alone cannam@147: constituted "time travel", and thought I was ridiculously over-hyping an already-well-known cannam@147: technique. My HN post was subsequently flagged into oblivion. cannam@147: cannam@147: Let me be clear: cannam@147: cannam@147: **Promises alone are _not_ what I meant by "time travel"!** cannam@147: cannam@147: cannam@147: cannam@147: So what did I mean? Perhaps [this benchmark](https://github.com/kentonv/capnp-vs-ice) will cannam@147: make things clearer. Here, I've defined a server that exports a simple four-function calculator cannam@147: interface, with `add()`, `sub()`, `mult()`, and `div()` calls, each taking two integers and\ cannam@147: returning a result. cannam@147: cannam@147: You are probably already thinking: That's a ridiculously bad way to define an RPC interface! cannam@147: You want to have _one_ method `eval()` that takes an expression tree (or graph, even), otherwise cannam@147: you will have ridiculous latency. But this is exactly the point. **With promise pipelining, simple, cannam@147: composable methods work fine.** cannam@147: cannam@147: To prove the point, I've implemented servers in Cap'n Proto, [Apache Thrift](http://thrift.apache.org/), cannam@147: and [ZeroC Ice](http://www.zeroc.com/). I then implemented clients against each one, where the cannam@147: client attempts to evaluate the expression: cannam@147: cannam@147: ((5 * 2) + ((7 - 3) * 10)) / (6 - 4) cannam@147: cannam@147: All three frameworks support asynchronous calls with a promise/future-like interface, and all of my cannam@147: clients use these interfaces to parallelize calls. However, notice that even with parallelization, cannam@147: it takes four steps to compute the result: cannam@147: cannam@147: # Even with parallelization, this takes four steps! cannam@147: ((5 * 2) + ((7 - 3) * 10)) / (6 - 4) cannam@147: (10 + ( 4 * 10)) / 2 # 1 cannam@147: (10 + 40) / 2 # 2 cannam@147: 50 / 2 # 3 cannam@147: 25 # 4 cannam@147: cannam@147: As such, the Thrift and Ice clients take four network round trips. Cap'n Proto, however, takes cannam@147: only one. cannam@147: cannam@147: Cap'n Proto, you see, sends all six calls from the client to the server at one time. For the cannam@147: latter calls, it simply tells the server to substitute the former calls' results into the new cannam@147: requests, once those dependency calls finish. Typical RPC systems can only send three calls to cannam@147: start, then must wait for some to finish before it can continue with the remaining calls. Over cannam@147: a high-latency connection, this means they take 4x longer than Cap'n Proto to do their work in cannam@147: this test. cannam@147: cannam@147: So, does this matter outside of a contrived example case? Yes, it does, because it allows you to cannam@147: write cleaner interfaces with simple, composable methods, rather than monster do-everything-at-once cannam@147: methods. The four-method calculator interface is much simpler than one involving sending an cannam@147: expression graph to the server in one batch. Moreover, pipelining allows you to define cannam@147: object-oriented interfaces where you might otherwise be tempted to settle for singletons. See cannam@147: [my extended argument]({{ site.baseurl }}rpc.html#introduction) (this is what I was trying to get cannam@147: people to click on yesterday :) ). cannam@147: cannam@147: Hopefully now it is clearer what I was trying to illustrate with this diagram, and what I meant cannam@147: by "time travel"! cannam@147: cannam@147: