People of Language Design and Implementation

An interview project in conjunction with PLDI 2019  

 

BL: Tell me about yourself.

SA: I grew up in San Diego and I went to Torrey Pines High School. I started programming in 6th grade and I got into programming because I was into gaming. My parents were like "that's not a real job". (They're both engineers). They said to me "that's not a real job, you've got to be a medical doctor".

So I go to college and I'm preparing to become a medical doctor. I was a microbiology major. I did good! I was good at the competing part. I could stuff massive amounts of knowledge into my head, which I could then later regurgitate. I also did some research, too. I worked at the Salk Institute. I did that in High School. I took AP biology and my teacher recommended me. I really like the research vibe there. I did genomics. I really liked the environment, but I didn't really like the work because it was all spreadsheet wrangling. Data analytics before there was really data analytics.

BL: When was this?

SA: This was in my junior and senior year in high school. I did it for multiple years and I really enjoyed the work I was involved in, even if it wasn't a perfect fit.

BL: You were on the path to a very different career in science, becoming a doctor. What changed in your interests?

SA: I started my undergrad as a biology major, but I started shifting toward things that were more computational. I did computational biology. At some point I realized, though, that I am not hugely motivated to help people. I know that sounds terrible. I interned at a hospital and shadowed a doctor. I was just like "This is not for me! Sick people are not fun". So my parents suggested I be a radiologist. But I thought to myself, if I'm going to sit in a dark room all day and work on a computer, why not just become a computer scientist? So I double-majored with computer science. I dropped the medical degree and picked up a biology major. I just realized that I am not strongly motived by altruism. I do research just because the problems are interesting. I basically just like problem solving.

In college, I was introduced to computer science research by Glenn Reinman, who taught the computer architecture class I took. That summer worked with Jens Palsberg on a compilers project as part of a heterogeneous computing initiative. I extended a Matlab compiler (written by a student) to target a C/C++ task-based programming language developed by Vivek Sarkar’s group. I hadn’t taken a compilers course at that point and ended up reinventing a lot of various loop transformations, but I had a lot of fun. That’s what drew me to programming languages research. And then after that I applied to grad school.

BL: I think it is interesting that in your past, you have worked on computational biology and studying these actual biological phenomena. Now in your work, you write compilers for analog computers that are really good for modeling these sorts of biological phenomena.

SA: As a computational biologist, I knew that differential equations were the center of it all. I believed in the problem domain.

BL: It is a bit of a privileged position, to study a domain and then to be able to work in a different field that directly supports that domain. Your work really brings together a lot of different areas: your lab is full of hardware and instruments, you're building solvers, and your papers are full of chemical reactions and differential equations. How have you managed to handle bringing all of these different pieces together in your work on analog computing?

SA: I definitely see that one of my strengths is to fall into things that I do not know very much about and to just figure it out. I took no circuit design classes when I was an undergrad, but it was necessary to know some of that stuff to figure out my work on analog computers.

When you're solving problems in CS, there's a certain amount of uncertainty. But when you're solving problems that span multiple areas, there's some additional uncertainty. One thing that I did that really helped was to have a network of friends in different areas and to then pick their brains a bit. For instance, I didn't really know a lot of the state of the art in stability in stochastic control systems. I got my friend a beer and we talked about it and he told me "If your problem isn't a polynomial problem, then it's basically impossible to say anything about its stability". I just wouldn't have known that otherwise, but apparently it's an active area of research and people can't even do it manually some of the time. When you're working so far out of your depth in some area, it's very useful to be able to pick someone's brain. Of course, you also have to solve some problems yourself, too. At some point, I did just have to get out the oscilloscope and do some measurements. One challenge was balancing that -- when to measure and when to ask someone else? I could easily spend all of my time doing measurements and never get anywhere. Meanwhile someone else may already know exactly what I need to know to make progress. I see it as mitigating uncertainty and the key is to understand which uncertainties to avoid before even starting to dig.

BL: Your recent work on new, analog computers bridges the gap between hardware and programming languages. How has that been?

SA: I think the biggest hurdle is to get people to understand what I'm actually doing. The high-level language is unfamiliar to people. The low-level hardware is often not familiar to people. The compiler is a bit exotic as a consequence. Doing this work has been a bit of an exercise in learning how to explain my work to people.

BL: What do you see as the outlook for your work, which features experimental hardware at its foundation?

SA: Let me answer by describing what it would be like if my work is successful. If my work is really successful, it will be at the basis of a compiler for this hardware or similar hardware. My work could apply to other spatial hardware where there is a physical mapping of the problem onto the system. I'm taking things from the 60s that people did on pen and paper (or even that some of my colleagues are doing on pen and paper) and automating it.

BL: That's a cool way of looking at the problem. It makes me think of early compilers automating the punching of cards for conventional computers.

SA: Sure, you could sit there and think really hard and come up with assembly, but why not instead use a compiler?

BL: Approximate computing seems to have been your segue into your analog computing research. How did you get started in approximate computing and how did you end up working on analog computers?

SA: It may not come as a surprise that it was not totally planned out. When I first started grad school, I got involved in a project called Chisel with some senior graduate students on approximate computing. From there, I moved on to working on my Topaz project, which is a distributed system that allows some principled approximation.

The jump to working on analog computing was also somewhat unexepected. My advisor went to a cocktail party and starting talking to some guy [Rahul Sarpeshkar] that claimed he had a really cool analog computer chip, but that it requires a PhD to be able to program it.

Learning more about the chip, I realized that there was a deep connection to approximate computing. These analog computers have much more well-characterized noise distributions than the error models for approximate computing on digital computers. In a way, I've moved away from approximate computing by moving to analog chips, but in a way, I've come back around and starting looking at the problem in a new context.

BL: Has the new context of analog hardware helped you think differently about approximation?

SA: I am interested in building things for novel hardware that was built by hardware people and I am interested in the constraints coming out of the constraints that the hardware actually has. If you tell a hardware person to design something that is low-energy, they aren't just going to undervolt a conventional computer. If you want to take quality as a metric into consideration, there had better be an incredible benefit there that you can get.

In a way we have fallen into the interesting problems in analog computing, which I think is my favorite way of identifying a new problem. It was very organic and we let our curiosity guide us as we explored this analog hardware platform.

BL: What are you into besides computers? Do you have any serious hobbies?

SA: My biggest interest right now is that I am on the radio. I am a DJ and I host a radio program. As part of being a DJ, we "eat our own dogfood" --- the whole station is analog and I also do side projects for the station. My big claim to fame there is that I did the call blocker for the station. Our phone system is also analog and we want to be able to block peoples' numbers. There end up being some technical issues, but also some social issues that make this interesting and complicated. For example, the person that designed all of the ICs [integrated circuits] for the station is very possessive of them. I have to also manage that. Being on the radio is the biggest thing that I do right now.

BL: What kind of DJ are you? What kind of music do you play?

SA: Oh, I don't play music. I play old timey horror stories. Stuff from the 1920s. Orson Welles' "War of the Worlds" is a classic one, but there's a whole genre of these stories. Pulp science fiction and pulp horror were a huge thing back then. I play two stories a week; I basically curate. I end up listening to horror stories all week and then I put together things that I think I want to play that week.

BL: That is at the MIT radio station?

SA: Yea, the MIT station. It is also interesting because everyone who is on the air is trained to comply with the FCC. I play stories, not music, so I've run into some interesting issues. Are you familiar with the emergency alert system? They use these short tones and these long tones and they bookend some message. Our station listens to lots of other stations and it's like a flooding algorithm. What happens is that our station captures these tones, interrupts our broadcast, and sends out the emergency message. Any stations that listen to us then re-broadcast that. One time I was playing a story --- I always edit my stories before I play them in case there is something objectionable and not FCC compliant --- and the story included the real emergency broadcast tones. That is a problem! If you're playing a zombie apocalypse story, the last thing you want to do is broadcast your zombie apocalypse story as an emergency message and have it propagate through the real emergency alert system.

BL: Did it actually get out into the world?

SA: I had to edit it out. Broadcasting that would have been very illegal.