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