Skip to main content

HotOS 2009, Day Three

HotOS wrapped up yesterday. (I'm now in Trento, giving a talk at the University of Trento tomorrow, meeting with colleagues at ArsLogica, and driving back to Milan on Saturday before heading home.)

Click here for some photos from HotOS 2009.

A few highlights from the last day:

Maysam Yabandeh from EPFL talked about Simplifying Distributed System Development, by using a dynamic controller that predicts a distributed system's behavior (based on code analysis) and automatically tuning its operation. This seems closely related to work on Dicrete Control Theory and Yin Wang's paper in Eurosys 2007.

Emre Kıcıman (note typographically-correct use of Turkish ı glyph) gave a talk on Fluxo, a "service complier" that takes a high-level description of an Internet service and maps it down onto an implementation with caching, replication, and service partitioning performed automatically. This seems like a fantastic idea to me, in line with the use of other "service frameworks" such as Rails and Turbogears, but going much further. The challenge I see is debugging and performance tuning the resulting system.

Finally, Vijay Vasudevan from CMU have my second-favorite talk of the workshop on FAWN, a design for compute clusters based on extremely power efficient nodes (ALIX boards with CF drives) that are intended to yield the highest number of operations per joule. The design space was well presented and I like how Vijay did not present this as the best solution for all possible workloads. I'd like to see what the total cost of ownership involves when you factor in wearout of the flash drives and MTTF of the hardware itself.

Overall I think this was the best HotOS that I have been to. The talks were generally very good and on interesting topics. The location was superb -- remote enough to keep people together, but with a decent town nearby. The level of interaction was extremely high, although I would have liked to see shorter talks and a bit more discussion and less requests to "please save your questions until the end." I wonder if they shouldn't have disabled the WiFi during the sessions, although I think most people were pretty engaged and asked good questions. Armando, Ellie, Mothy, and the rest did a great job pulling it together.


  1. Highest joules per operation?

  2. My bad. Flip that - "highest number of operations per joule" - just edited.


Post a Comment

Popular posts from this blog

Why I'm leaving Harvard

The word is out that I have decided to resign my tenured faculty job at Harvard to remain at Google. Obviously this will be a big change in my career, and one that I have spent a tremendous amount of time mulling over the last few months.

Rather than let rumors spread about the reasons for my move, I think I should be pretty direct in explaining my thinking here.

I should say first of all that I'm not leaving because of any problems with Harvard. On the contrary, I love Harvard, and will miss it a lot. The computer science faculty are absolutely top-notch, and the students are the best a professor could ever hope to work with. It is a fantastic environment, very supportive, and full of great people. They were crazy enough to give me tenure, and I feel no small pang of guilt for leaving now. I joined Harvard because it offered the opportunity to make a big impact on a great department at an important school, and I have no regrets about my decision to go there eight years ago. But m…

Rewriting a large production system in Go

My team at Google is wrapping up an effort to rewrite a large production system (almost) entirely in Go. I say "almost" because one component of the system -- a library for transcoding between image formats -- works perfectly well in C++, so we decided to leave it as-is. But the rest of the system is 100% Go, not just wrappers to existing modules in C++ or another language. It's been a fun experience and I thought I'd share some lessons learned.

Why rewrite?

The first question we must answer is why we considered a rewrite in the first place. When we started this project, we adopted an existing C++ based system, which had been developed over the course of a couple of years by two of our sister teams at Google. It's a good system and does its job remarkably well. However, it has been used in several different projects with vastly different goals, leading to a nontrivial accretion of cruft. Over time, it became apparent that for us to continue to innovate rapidly wo…

Running a software team at Google

I'm often asked what my job is like at Google since I left academia. I guess going from tenured professor to software engineer sounds like a big step down. Job titles aside, I'm much happier and more productive in my new role than I was in the 8 years at Harvard, though there are actually a lot of similarities between being a professor and running a software team.

I lead a team at Google's Seattle office which is responsible for a range of projects in the mobile web performance area (for more background on my team's work see my earlier blog post on the topic). One of our projects is the recently-announced data compression proxy support in Chrome Mobile. We also work on the PageSpeed suite of technologies, specifically focusing on mobile web optimization, as well as a bunch of other cool stuff that I can't talk about just yet.

My official job title is just "software engineer," which is the most common (and coveted) role at Google. (I say "coveted&quo…