The Tale of GridRuby

While in graduate school, my friend Chris and I took a seminar class together on object-oriented programming. Being a graduate-level seminar class, there was a lot more interactivity and student involvement than in a typical lecture. As is typical for the computer science department, there was also a project.

(Warning: the contents of this post are more technical than most. Hopefully there’s enough of interest in here for the nontechnical to enjoy, but I will not be hurt if anyone chooses to skip this one.)

Naturally, Chris and I formed a team to work on the project. As our love of the Ruby programming language is legendary, it should come as no surprise that we chose to do our project in Ruby. And as both of us were part of the systems programming group — myself focused on operating systems and software engineering, Chris focused on distributed systems and high-performance computing — we immediately began thinking along systems programming lines for our project.

This was no rinkydink presentation software project. This would be epic.

The idea we came up with was honestly epic enough to be a master’s thesis in itself. Essentially, we were to use the Ruby language to create a framework for running programs that needed to perform a lot of work across a distributed network of loosely-coupled dissimilar computers (referred to as a grid, different from a cluster which is a distributed network of tightly-coupled similar computers or compute nodes).

The topic of parallelizing applications which were not explicitly designed to be run across multiple computers was a Big Deal in 2006, and remains an interesting research problem to this day. There had been a number of projects which demonstrated the utility of a highly distributed global-scale network, such as Folding@home or the system for cracking encryption ciphers. There were extremely structured programming frameworks such as MPI that developers could use to parallelize their programs. But we weren’t aware of any general-purpose framework for parallelizing applications which were not already designed to be run in parallel.

One of the cool features of the Ruby language was that it could bind to lower-level languages like C natively. This was important because Ruby is a fairly slow language and is not used for high-performance computing, but C is more difficult to write in. By making use of this bridge, we could write the bits that were OK to be slower in Ruby and the client code could be written in C.

We did an absolutely monumental amount of work for this project, pulling a few all-nighters to get it done (Chris’ fiancée really deserved to be listed as a co-author on the paper for how often she made us dinner…and breakfast…and lunch…so we could focus on cranking out the code). We utilized several advanced software engineering techniques such as code generation from a domain-specific language and declarative programming. We learned on the go and worked together in extremely tight synergy, rarely stumbling over communication hurdles or knowledge gaps that often plague teams.

One of the many diagrams we created to help others (and ourselves) understand how our project worked.

We even had some real-world numbers. Chris’ graduate research focused on parallelizing a bioinformatics tool called BLAST, so we hooked BLAST up to run inside our framework. I also wrote a series of simple clients of our framework for doing a text search across a corpus in C, C++, and Ruby, to demonstrate both that our framework was general-purpose enough to support multiple clients and also that it could support multiple programming languages. Our numbers were actually really good. Chris wound up incorporating some of our work into his master’s thesis!

As the deadline loomed, the code neared completion. Chris finished up some loose ends while I wrote the paper describing our work. Finally, we worked together on the most important artifact: the presentation. We were to present our work to the class. It was very challenging to condense our work into the 10 minutes we were allotted, and unfortunately we wound up having to cut a lot of material for time. We didn’t really even have time for a full demo to prove that our project was fully functional.

As luck would have it, our group was first. We stood up in front of the class and tried to condense as much information as possible into our allotted 10 minutes. I like to think that our presentation was OK, but I’m sure it was rushed and a bit disjointed given the time constraints. But we knew we had created something special, something that really transcended a mere class project. When we finished and sat down, we knew we had given it the best shake we could.

As the other presentations went on, our good spirits sank. Every other presentation went way over the 10-minute limit we were given, and the professor did not seem to care. A couple of the other projects were also genuinely excellent, but most were fairly middle-of-the-road. However, we were the only project without a demo, and our presentation looked more and more rushed and amateurish next to these 17 – 25-minute presentations.

After the grading was done, we were devastated to receive a “B” for our work. That grade felt like a slap in the face after all we had done! And worst of all, we knew we deserved better! Chris’ thesis advisor even asked the professor if he would reconsider the grade, but he didn’t seem interested in hearing us out. It felt like he pre-assumed that we were just trying to protest a grade we didn’t care for and it didn’t even occur to him that we could have been evaluated unfairly in any way.

Graduate school is not easy. Much of it for me was a blur of not enough sleep and way more work and stress than I was truly capable of handling. Not to mention the fact that I was also working 20 hours a week and trying to find a full-time job for once I graduated. And the end of the year is the hardest and busiest time of them all. Ultimately, we ran out of time and energy to fight the grade, and it stuck. We still ended up getting “A”s in the course, but we didn’t care…honestly, we didn’t even care if the grade stuck or not. We just wanted the recognition for what we’d accomplished. It felt like we were in the Twilight Zone somehow, where we both believed we had created something very special and wonderful, but nobody else seemed all that interested in it.

After the semester finished, I had a conversation with the professor. It turns out one of the problems was that he didn’t really believe that we could have created what we said we created, and without a demo to prove our work, he assumed we hadn’t delivered on the bold statements we made about what we had created. In a way, to put a positive spin on it, what we created was actually so impressive that the professor didn’t believe it! This was slight solace, but to this day I feel we were wronged.

The ultimate revenge would have been to write up a treatment of what we created and get it published in a peer-reviewed journal. But neither of us had the time for that, so we had to let it go.

Of all the might-have-beens of my life, one of the ones I look back on with the most regret was GridRuby. It is what it is, and of course the discipline of distributed computing has advanced significantly without our contribution. And perhaps what we had created was interesting and cool but ultimately nothing significant or novel.

But maybe, just maybe, it could have made us famous.

2 thoughts on “The Tale of GridRuby

  1. How sad that he didn’t admit to the possibility that you might have accomplished what you said you did and let you demonstrate it to him later. But life is full of unfairness, so I’m glad you were able to move on despite the disappointment.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Create your website with
Get started
%d bloggers like this: