Getting the Harvard IR Swap Story Right, Programming is Hard, and NAG in Jenkins

Brad DeLong, Grasping Reality, Illegitimate and Unfair Larry Summers Bashing: The Smart and Thoughtful Matthew Klein Gets One Wrong, here.

As I understand the story, this is completely garbled. As I understand the story, this is how it went down:

• In 2004 Larry Summers decides that Harvard should expand massively into Allston/Watertown in the late 2000s–and that it should in the late 2000s borrow massively in order to finance that construction project.
• Harvard’s debt management committee worries about the extra burden on Harvard’s cash flow that would be imposed if interest rates were to rise between 2004, when the planning begins, and 2008, when the money is borrowed.
• Harvard’s Debt Management Committee decides to hedge the risk that interest rates will rise by taking on a huge long-run swap position–thus insulating itself against losses if interest rates rise, but also giving up the gains that would otherwise accrue if interest rates were to fall. Summers does not overrule but rather approves the DMC.
• Summers resigns the Harvard Presidency in mid-2006.
• Successors Bok and Faust cancel the expansion.
• Harvard’s DMC does not liquidate its swap position now that it is no longer a hedge, and so turns it into a very large directional bet that Treasury interest rates are going to go up.
• In late 2008, in a panic during the panic, Harvard’s DMC sells the position at the bottom, when it is worth the least.

Rachel Courtland, IEEE Spectrum, What Intel’s Xeon Phi Coprocessor Means for the Future of Supercomputing, here.

As with any machine that pairs CPUs and accelerators, Blue Waters’ programmers must find effective ways to transport data between the chips, a process that can consume a lot of power. “Anything you do has to be a big enough lump of work in order to amortize moving the data over,” Gropp says. This makes programming more difficult: “You have to figure out how to aggregate [work] into a lump whose size is not based on the characteristics of your problem but the characteristics of your hardware.”

NAG Blog, Jenkins comes to NAG, here.

In the time since we looked at Buildbot and Hudson we’d heard good things about Jenkins, a fork of Hudson (but no relation to Leeroy). I tried Jenkins out on some small projects and I saw good things. The GUI makes it a doddle to experiment with a set up. There are lots of nice, relatively-mature and well-maintained plugins for email notifications, tracking violations of user-defined coding standards, reporting on code coverage, Chuck Norris, … So we set up a small group to prototype a new configuration for use by the whole company, and then, all going well, to port over the old system.

The NAG Jenkins is getting off the ground at the moment. Here are some things we’ve implemented and discovered (i.e., been burned by).