Haven’t updated my blog lately. I was mostly busy with a paper submission due a few days ago. Now that paper is submitted, I am ready to prepare for another one.
Time flies, and my happy summer time is less than 1.5 months remaining. I am hoping to finish one paper (expecting to get this done by end of July), and start to work on another, and help my labmates with others.
ResearchGate is a social network website for researchers. It’s something similar to LinkedIn as to business people/professionals, but RG is geared towards researchers and scientists. ResearchGate lets you connect to other researchers, and let you upload the publication so that other people can download.
I personally find it useful. I host my workshop paper here in my blog for downloading, but I don’t seem to get any traffic. But since I uploaded it to RG, that paper has been downloaded several times. It could enhance my academic impact, I think.
We submitted a paper yesterday that describes our system. It’s anonymized submission so I can’t talk about the details.
But let me talk about the engineering effort.
We’ve wrote 40 thousand lines of code in the past one and half years, and we’ve checked in almost 1000 changesets in this period. I am the main contributor and wrote about 60% of all the code. But this is a large project. We had six people working on this project, either contributing the code, testing the system or providing suggestions, so that’s equivalent to more than a hundred man-months!
All of the effort is simply for publishing one research paper. Phew! This is not easy!
Our manuscript to PLDI was reject unfortunately. However, I do think our work has tremendous value. I definitely want to resubmit it to a different venue.
My labmates also suffer from rejections recently. This is not a particularly great new year for my lab 🙁
We have just submitted our latest work to PLDI (Programming Language Design and Implementation), a top conference in the programming language area today!
Thanks for every one’s contribution, and it’s great to have six people working on the same paper (i.e. on average, every one just need to write less than two pages) We had some last-minute issue last night, but thankfully we were able to workaround and get the result in time.
Also, we have the 700th changeset committed by Rui Gu today just before the paper submission!
As we’re approaching the PLDI deadline, we have reached another (small) milestone: the 650th commit. Now, almost everything are implemented, and we’ve made tremendous effort trying to optimize all aspects of the runtime system. Hopefully we can submit to PLDI and get accepted!
After 10 months of hardwork, the 600th changeset is committed! Also, since last December, we’ve contributed more than 30,000 lines of code. This is a really huge project!
Here’s an introduction to our HotDep’12 paper
While the word ‘cloud-computing’ has become a cliché, the real strength of cloud is not yet undermined.
Elasticity, the ability to scale up or scale down the application on demand, is not understood clearly to date. There are a few exception though, such as MapReduce or bag-of-tasks type of applications. However, These programming paradigms are simple, usually stateless, and therefore easy to perform dynamic provisioning and so on. For more general type of applications, there has been very little research on how to enable elasticity to them.
We propose a programming model which enables elasticity. Moreover, it makes the programmer easy to reason about the execution of the application in elastic environment. In the model, an application runs in a “logical node.” A logical node is composed of multiple “physical nodes.” Regardless of the number of physical nodes involves in a logical node, an event executed in a logical node is logically equivalent.
However, elasticity induces a new fault-tolerance issue. A naive elasticity scheme would increase failure rate by allowing a physical node failure to induce the entire logical node failure.
Interesting, we found the mechanisms of the programming model naturally provides a solution to the fault-tolerance problem. Specifically, our programming model can recover failures at per-physical-node basis, and thereby transparently masks the physical node failures. More details of the programming model and the failure tolerance mechanisms can be found in the paper.
Our Hotdep12 Paper