
Experience with ePaxos: Systems Research using Go - ste5en
http://da-data.blogspot.com/2013/10/experience-with-epaxos-systems-research.html
======
micro_cam
This mirrors my own experience using go to write software used in biological
research. Performance is good enough and the quickened dev cycle due to less
verbosity and excellent tooling makes implementing variations on algorithms
easy.

Ie I wrote a random forest implementation [1] and i've been able to quickly
add in a bunch of different published and experimental variations on the
algorithm as needed for the data sets I work on.

[1]
[https://github.com/ryanbressler/CloudForest](https://github.com/ryanbressler/CloudForest)

------
assface
> _Paper weaknesses_

> _Evaluated using prototypes of protocols in Go_

Retarded. This is why I left academia.

~~~
dgacmu
Eh. (blog author here). It was exceptionally annoying, but in the end, the
paper got in. You have to develop a thick skin, but I've found that in the
long run, the process works pretty well. The feedback we got from our first
submission to OSDI was _awesome_ , and helped seriously improve the quality of
the research, not just the paper. (It led us, for example, to adding the
formal proof and the machine-checkable proof.) The NSDI feedback was crappy.
I'm disappointed, because I like NSDI a lot. I think people were just having a
bad-Paxos day. The final SOSP feedback was again really good.

~~~
fintler
I'm someone who's happy you put the proofs in there.

As soon as I read "has no designated leader" I stopped reading and skimmed
through to make sure safety and liveness proofs were in there somewhere before
I spent any significant time reading the rest.

This feels like it's probably a nice advancement over S-Paxos and I'm looking
forward to getting through it -- thanks for making it accessible.

Also, this is awesome: "Copyright is held by the Owner/Author(s)"

~~~
dgacmu
That last awesomeness is SIGOPS: They bought out the copyright for all papers
at SOSP'13 on behalf of the authors. _three cheers_. All of the SOSP papers
are available -- already -- open-access:
[http://sigops.org/sosp/sosp13/program.html](http://sigops.org/sosp/sosp13/program.html)

(For the non-academics: SIGOPS is the chapter of the ACM for operating
systems. It runs SOSP and similar things.)

------
Daishiman
How does Go compare to modern C++, using the newer feature and libraries
without the old cruft?

~~~
dgacmu
From a systems perspective: Dealing with lots of communication and having lots
of concurrency _where the concurrent actors are doing a lot of different
stuff_ is easier in Go.

Achieving high performance on a single machine and building reusable data
structure libraries is easier in C++. Things like vectorization, cache-
optimized layouts, etc., are all more easy here (or just in C).

~~~
JulianMorrison
What were the general techniques you learned for optimizing Go?

~~~
dgacmu
Good question. I'm not sure I have a great mental list that differs from the
"go community conventional wisdom" (whatever that is), but it was basically:
\- Avoid creating garbage unnecessarily, but don't go too crazy. It's often
enough to, e.g., statically size those things you know are static. We tried
adding a structure cache to our RPC/marshaler to further reduce GC, but it
didn't prove helpful and just complicated our interface. \- Pre-size data
structures when you can (maps, arrays): Reduces performance variation as they
dynamically resize. \- Be careful of using introspection for things like
marshaling. It's easy to create a bottleneck. \- Batching is just - or more -
important as it is in C++. \- When you're doing complex stuff, be deliberate
with how you prioritize request handling ( _).

More on (_): We found it incredibly important for the performance of our
system to prioritize processing of existing requests over processing new
request arrivals - up to a point. Making progress on an existing request helps
_reduce_ the number of goroutines/objects/etc. that're processing, so that
everything runs faster. But you don't want to go too far or you starve for
work. The key here was to think about it instead of letting your design happen
to you.

The most important is already known: Profile, don't guess. The profiling Go
article is a good start.

