Back in September, I wrote about what the first half of grad school was like for me. That post covers a period of about three years, from the middle of 2008 to the middle of 2011. I've been wanting very much to write the companion piece covering the second half of grad school, but so far, I've been hampered by the fact that most of the second half of grad school has not actually transpired yet.
Still, I'm willing to give it a shot!1
To recap from last time: while I was at Mozilla working on Rust last summer, my advisor invited me to come with her to Northeastern University for the rest of my Ph.D., which meant that I had to choose between IU and NU. It was an extraordinarily difficult decision to make. NU has a world-class group of PL researchers; living in Boston probably would have been cool; and, of course, I'd have gotten to keep working with Amal in person. But my husband, Alex, is also in the middle of his Ph.D., and while it hasn't been nonstop rainbows and sunshine for him here at IU, starting over at yet another school (assuming he could find a graduate program in Boston that was a good fit for him), and then probably having to take yet more courses and jump through more qualifying exam hoops, would be far worse. Living apart isn't a viable option for us, either -- we did that for a year and a half, and we're not interested in trying to do it again. (Empirically, if we're apart for more than a week these days, I go nocturnal and spend all my time either reading genre fiction or watching the same Lady Gaga video over and over. Bad scene.)
So, when I got back to school last August, I started working with a new advisor, Ryan Newton, who had just joined the faculty at IU. I'm now being advised by both Amal and Ryan, but Ryan is who I see day to day. I've spent a lot of time in the last several months telling Ryan about my work with Amal, and now that Ryan and I have a project going as well, I've started to do some of the reverse. Happily, I learn a lot in the process of doing so!
In order to get a better sense of the kind of research Ryan does, I took his course on embedded DSLs for parallelism in the fall. This was a new area for me to be reading in, and one of the papers that particularly grabbed me was about the Concurrent Collections system that Ryan had worked on while he was at Intel (abbreviated "CnC", as per some Intel marketing team). The paper had a proof of determinism for a parallel language called Featherweight CnC that's a lightweight model of full CnC. I noticed that the determinism proof hinges on a monotonicity lemma that says that if one state s in the semantics steps to another state s', then either s' is an error, or the store in s' is a valid extension of the store that s had. The monotonicity lemma, in turn, hinges on a single-assignment property, which states that we can only write to previously unused memory locations. It was the sort of thing that smelled like it might fit into a possible-worlds semantic model like the ones that I have some familiarity with from working with Amal. I was also curious about the analogy between the single-assignment property and the "weak updates only" requirement that some systems have, which requires that updates to a store can only change the value, not the type, of the contents of a cell -- and whether any of the tricks that allow loosening of the weak-updates-only requirement had analogues that would allow loosening of the single-assignment restriction.
When I went to talk to Ryan about that, it turned out that he had also been thinking about loosening the single-assignment restriction on single-celled I-structures, sometimes known as IVars, which are the communication mechanism that the Haskell monad-par package uses. If it's okay to write to a cell once, it seems like it should be fine to write the same value multiple times. But at that point, it would be interesting to try to loosen the notion of "same" and replace it with a less restrictive equivalence relation. "Values that unify with each other" is one possibility that Ryan brought up; for me, good ol' "values that are indistinguishable for a given number of steps" comes to mind. Also, what would happen if we parameterized a language by an equivalence relation for sameishness, lambda-eek-style? What properties would have to hold of that equivalence relation to make the language deterministic? (Wren sloganed this idea as "determinism modulo theories", which I like.) Or, what about only allowing writes of values that are monotonically increasing according to some partial order that we also parameterize the language by? And speaking of monotonicity: what do the notions of monotonicity that turn up in various models of deterministic parallel computation -- for instance, in monad-par, in CnC, and in Kahn process networks -- have in common? What would it look like to have a unified theory of monotonicity that's general enough to account for existing deterministic parallel models as well as guide the design of new ones?
By the time we were asking all these questions, it was late November, and Ryan suggested that we end the semester by writing a grant proposal. The NSF solicitation that he had in mind had a deadline of December 19th, so there was no time to waste, but we worked hard and got the proposal submitted on time. (Hooray!) "Generalizing Monotonic Data Structures for Expressive, Deterministic Parallel Programming" is the title of our proposal. It'll probably be a few months before we find out whether it will be recommended for funding, but one nice thing about being in theoretical CS is that there's no big outlay of funds needed to get a project off the ground -- the tools of our trade are pretty cheap.2 So we've been able to get started on the work anyway, and it's going to be my main focus for the next month.
In the meantime, the project that I've been working on with Amal for the last two years (!) is still underway. I made a trip to Boston back in October to work on it, and I'll be there again in mid-March. We were also able to sneak a little time to work on it during POPL last month. (While at POPL, which was awesome, I also had the chance to pick lots of clever people's brains about monotonic data structures, and I got some cool ideas that I'm still in the process of following up on and that I hope to have more to say about soon.) So, I'm still juggling separate research projects, but so far, I've mostly managed to work on each one for enough time at a stretch that the context-switching overhead doesn't kill my productivity. It also helps that I'm finally done taking classes, plus, this semester Ryan is funding me, so I don't have to work as a teaching assistant in order to pay the bills. So, all things considered, I'm very happy about how things are going! Although it's too early to say for sure, I think it's likely that I'll propose a thesis that has to do with the monotonic data structures project sometime in the next year or so, after we've submitted a paper or two. I'm excited about that, and I'm looking forward to seeing what the next couple of years will bring.
I'll end on that note, but first, one thing bears some explanation. Back in July, I was thinking I might want to develop an intermediate language for LLVM-based compilers (of which the Rust compiler is an example) as my dissertation work. Although that would be a cool project, it probably isn't the right project for me. I'm interested in doing more theoretical work. I probably won't be interested in doing more theoretical work forever, and in fact, I really enjoy doing heads-down compiler hacking, plan to do some more of it this summer, and could imagine myself doing a lot more of it after I graduate. I just don't particularly want to do it for my Ph.D.
If I'm completely, unflinchingly honest with myself, one reason that hacking on a Rust-related project came to mind as a potential thesis topic back in July was because right then, I was grappling with the decision between IU and NU, and some part of me fantasized that if I could get Mozilla to fund my research, then it wouldn't matter so much who my advisor or institutional affiliation was, and I could just avoid the decision entirely. Problem solved, right? Except, no, not at all, because the thing is that I would like to actually get a Ph.D. at the end of all this, and Mozilla, for all the cool things that it is, is not a degree-granting institution.3 Moreover, Mozilla would like me to actually get a Ph.D. at the end of all this, and as Dave Herman, my fantastic mentor at Mozilla, pointed out, they can only fund Ph.D. students for projects that the student's advisor is actively involved in, because otherwise, the student would essentially be doing contract work for Mozilla. That's not to say that there's anything wrong with doing contract work for Mozilla, of course, but you can't get a Ph.D. that way. An advisor is much more than a source of funding; an advisor is someone who guides their students through the grad school process and, along with the rest of a student's committee, eventually signs off on their Ph.D. So, although there are various ways to fund a Ph.D., to actually get one you really need to have an advisor -- or two.
- Part of my job as a researcher is to try to make informed guesses about the future, right? If I wanted to really be cute, I could even title this post "The Next 700 Days of Grad School." The timing probably isn't even too far off.
- Although we do have to get paid sooner or later, which is why we need to apply for grant funding.
- At least, not yet. We'll have to see how far this whole Open Badges thing goes.