2013-12-13-promise-pipelining-capnproto-vs-ice.md 4.03 KB
Newer Older
1 2
---
layout: post
Kenton Varda's avatar
Kenton Varda committed
3
title: "Promise Pipelining and Dependent Calls: Cap'n Proto vs. Thrift vs. Ice"
4 5 6
author: kentonv
---

7 8
_UPDATED:  Added Thrift to the comparison._

9 10 11 12 13 14 15
So, I totally botched the 0.4 release announcement yesterday.  I was excited about promise
pipelining, but I wasn't sure how to describe it in headline form.  I decided to be a bit
silly and call it "time travel", tongue-in-cheek.  My hope was that people would then be
curious, read the docs, find out that this is actually a really cool feature, and start doing
stuff with it.

Unfortunately, [my post](2013-12-12-capnproto-0.4-time-travel.html) only contained a link to
Kenton Varda's avatar
Kenton Varda committed
16
the full explanation and then confusingly followed the "time travel" section with a separate section
17 18
describing the fact that I had implemented a promise API in C++.  Half the readers clicked through
to the documentation and understood.  The other half thought I was claiming that promises alone
Kenton Varda's avatar
Kenton Varda committed
19 20
constituted "time travel", and thought I was ridiculously over-hyping an already-well-known
technique.  My HN post was subsequently flagged into oblivion.
21 22 23 24 25

Let me be clear:

**Promises alone are _not_ what I meant by "time travel"!**

26
<img src='{{ site.baseurl }}images/capnp-vs-thrift-vs-ice.png' style='width:350px; height:275px; float: right;'>
27 28 29 30 31 32 33

So what did I mean?  Perhaps [this benchmark](https://github.com/kentonv/capnp-vs-ice) will
make things clearer.  Here, I've defined a server that exports a simple four-function calculator
interface, with `add()`, `sub()`, `mult()`, and `div()` calls, each taking two integers and\
returning a result.

You are probably already thinking:  That's a ridiculously bad way to define an RPC interface!
Kenton Varda's avatar
Kenton Varda committed
34 35 36
You want to have _one_ method `eval()` that takes an expression tree (or graph, even), otherwise
you will have ridiculous latency.  But this is exactly the point.  **With promise pipelining, simple,
composable methods work fine.**
37

38 39 40
To prove the point, I've implemented servers in Cap'n Proto, [Apache Thrift](http://thrift.apache.org/),
and [ZeroC Ice](http://www.zeroc.com/).  I then implemented clients against each one, where the
client attempts to evaluate the expression:
41 42 43

    ((5 * 2) + ((7 - 3) * 10)) / (6 - 4)

44
All three frameworks support asynchronous calls with a promise/future-like interface, and all of my
45 46 47 48 49 50 51 52 53 54
clients use these interfaces to parallelize calls.  However, notice that even with parallelization,
it takes four steps to compute the result:

    # Even with parallelization, this takes four steps!
    ((5 * 2) + ((7 - 3) * 10)) / (6 - 4)
      (10    + (   4    * 10)) /    2      # 1
      (10    +         40)     /    2      # 2
            50                 /    2      # 3
                              25           # 4

55 56
As such, the Thrift and Ice clients take four network round trips.  Cap'n Proto, however, takes
only one.
57 58 59

Cap'n Proto, you see, sends all six calls from the client to the server at one time.  For the
latter calls, it simply tells the server to substitute the former calls' results into the new
60 61 62 63
requests, once those dependency calls finish.  Typical RPC systems can only send three calls to
start, then must wait for some to finish before it can continue with the remaining calls.  Over
a high-latency connection, this means they take 4x longer than Cap'n Proto to do their work in
this test.
64 65

So, does this matter outside of a contrived example case?  Yes, it does, because it allows you to
Kenton Varda's avatar
Kenton Varda committed
66 67 68 69 70 71
write cleaner interfaces with simple, composable methods, rather than monster do-everything-at-once
methods.  The four-method calculator interface is much simpler than one involving sending an
expression graph to the server in one batch.  Moreover, pipelining allows you to define
object-oriented interfaces where you might otherwise be tempted to settle for singletons.  See
[my extended argument]({{ site.baseurl }}rpc.html#introduction) (this is what I was trying to get
people to click on yesterday :) ).
72 73 74 75 76

Hopefully now it is clearer what I was trying to illustrate with this diagram, and what I meant
by "time travel"!

<img src='{{ site.baseurl }}images/time-travel.png' style='max-width:639px'>