Lars Bergstrom

Today, I finished off two reviews for PLDI 2011 (http://pldi11.cs.utah.edu/), one of the biggest conferences in programming languages research. I enjoy opportunities to perform these reviews, even though they still take me somewhere between six and eight hours each. Why?

Professional debt

Each paper is reviewed by 3-5 people, depending on the conference. So, if you submit a paper, you accrue a debt of 3-5 papers (admittedly, split with your co-authors). As a young graduate student, you can’t provide concrete feedback. Even at my stage, later in my graduate career but still a year or so away from completion, I can only provide reviews in a few very narrow areas. Given the number of people who will submit, graduate, and never pay off their debt, just keeping the whole research publication game alive requires you to review quite a few per year!

Programming languages reviews are fantastic

It always impresses the other University of Chicago graduate students in areas like supercomputing and theory when I tell them about the quality of reviews in PL. Overwhelmingly, every review we’ve gotten for Manticore has been thorough, deep, and insightful. Not just one long and detailed response per submission, but nearly every individual review, from major conferences to workshops to journals to even NSF grant proposals! I enjoy attempting to meet that high bar set by my peers and find the kinds of persnickety technical details, key missing related work, and insights about wider applicability or opportunities for extension that we’ve been given on our project. Seeing my review next in its place next to 2-4 other reviews of a paper can be humbling, especially when I’ve missed a glaring error or come away with a different position on the paper than all the rest of the reviewers.

Really understand the submission

Short of implementing the meat of a paper or reproducing its proofs by hand, writing a thorough and constructive review is the best way for me to believe I really understand what the paper is presenting. What does it build on? Do I believe its claims? How did they evaluate their results and is that a meaningful measure of their claims?

I attempted to sell a piece of electronics this weekend. I priced the bid reasonably, and put a Buy Now value that was much higher, “just in case.” The first bite was international and fairly innocuous, to the Phillipines. But:

I’ll take the express mail international for $46. Can you send me a paypal money request for the shipping price plus the buy it now price? I did a lot of shopping last friday and I just wanna make sure that I have enough to pay you. My paypal is UnrelatedToEBayUserName@yahoo.com thanks!

For those not in the know, eBay Seller (and Buyer) Protection only happens if you perform the purchase through the site. As soon as you go directly to PayPal, you’re out of luck. They can use either a hacked account, whose purchases will revert when the hack is finally investigated, or just dispute and cancel the payment. You have no recourse. After requesting the purchase directly through eBay, he went away.

Later, I got mail that the item had sold! But wait:

Hello Seller How are you. I am XXXXX i am contacting you because of your item that i won on ebay and i want it shipped to my son who is in west Africa. He is doing his birthday next week. i will be responsible for the shipping cost and i will be paying you through paypal. if you are ok with it get back to me with the invoice and your PAYPAL ID Here is my SemiRelatedToEBayUserName@yahoo.com so that i can make the payment to your account once, I will provide paypal the shipping address once i pay for the item.

I would like to have the item shipped to the address below:
XXXXX XXXXX
MOBOLAJI BANK ANTHONY WAY
IKEJA, LAGOS 23401 Nigeria

Seriously? Nigeria?

EBay has certainly done one positive thing — my Craigslist experiences now seem like a fraud-free dream.

I recently gained access to Intel’s Academic Manycore Testing Lab (MTL) to do some performance testing work on our compiler and runtime, Manticore. This environment contains 3 quad 8-core machines, one accessible via SSH and the others with an easy job queueing system. Over the two-week period I had access, I didn’t get as much done as I’d like, but I did find out quite a bit.

We continue to scale well past 16 cores

We have shown in the past that Manticore scales very well on a variety of benchmarks up to 16 cores. But, this time we’ve been able to show that we continue to see speedups all the way to 32 cores! Of course, there’s also bad news. While we have decent speedups at 16 cores and admirable speedups (relative to competitive implementations of the chosen benchmarks) at 24 cores, our 32 core speedup is only slightly better than that of 24 cores on some benchmarks. We need to do better. And more, we need to figure out where the bottleneck is!

We had a huge GC bug lurking, more than a year after our last one

Our benchmarks and output in general have gone through some very heavy stress testing, on decently sized manycore machines. However, whenever you double the number of cores, you can expect to find something new. And in this case, on one of the 3 machines, SMT is enabled, allowing 64 cores of testing. And at load… there’s a garbage collection bug. Three days of groveling over the heap, generated assembly, and instrumented binaries enabled me to work around it, but one of the downsides to a highly parallel garbage collector and pretty complicated scheduler is that when there’s a bug, it can take a while to track down the real root cause.

SMT does not appear to be useful for high-computation loads

At least for the sorts of work that most of our benchmarks have, SMT (which doubles the number of available cores by allowing two threads of work per physical core) does not offer significant advantages. Of course, this will need more investigation. Right now, when we spawn up additional threads, they each need their own nursery for garbage collection. But, we don’t resize those nurseries so they will all fit within the L3 cache size, potentially causing some memory thrashing that isn’t evident without the additional SMT threads. I also suspect the poorer speedups at lower numbers of processors is due to densely packing processes rather than packing densely at the package and core level but using extra SMT cores last.

Want to learn more? Well, this and other results are the topic of a large journal paper we’re writing on our work building the Manticore runtime system, which was specifically designed to take advantage of manycore architecture machines. Of course, in the journal paper there will be real numbers, rudimentary statistical analysis, and concrete recommendations. This article is just a post to thank the fantastic folks at Intel for making the Manycore Testing Lab available. I highly recommend it to anyone in an academic setting who doesn’t have an extra $30k to spend on one of these machines. Well, after I finish slamming those machines with work myself, of course!

After nearly a decade and a half of self-hosting lars.com as static, basic HTML-only website, I am finally shifting to a hosted service where I no longer need to rely on emacs to set my Last Modified Date. The motivation? Matt Might’s blog tips for academics. In short, despite being in the middle of a journal paper, a Ph.D. candidacy document, and two conference papers, I need more writing practice. The move to a hosting site that encourages writing will hopefully light that fire.

And, it certainly won’t hurt to discuss various persnickety details of Manticore, our parallel mostly-functional programming language and runtime, that don’t merit publication.