Computer Science on Bulrush Labs — Richard Tibbetts

Proactive Assumption Violation: Avoiding Bugs By Behaving Badly

Sun, 14 Nov 2010 23:38:00 +0000

Bugs are a fact of life in software, and probably always will be. Some bugs are probably unavoidable, but a lot of bugs can be avoided through good architecture, defensive programming, immutability, and other techniques. One major source of bugs, especially frustrating bugs, is non-deterministic behavior. Every programmer has experienced bugs which don’t reproduce, which require a special environment, or special timing, or even just luck to make happen. To avoid these bugs, programmers learn to favor determinism, making sure their software behaves the same way every time.

Platonic Browser Session Management

Mon, 26 Jul 2010 01:04:00 +0000

Firefox just crashed, and when I restarted it I was informed that it had some trouble reopening my 115 tabs. Understandable, but I went ahead and clicked the button that encouraged it to try harder. The result, after consuming what would have been several thousand dollars of computer time back when they charged for it, is that I’m back in the mess I made myself, with an unmanageable collection of pages open, covering topics like faucets, washing machines, coffee brewing, JVMs, whatever else came out of Google Reader, and the research I was doing for this post.

DEBS 2010 Highlights

Sun, 18 Jul 2010 22:49:00 +0000

I spent the first half of last week at DEBS 2010 at King’s College in Cambridge, UK. It was a great conference, many good papers and interesting attendees. As usual some of the best ideas came from the hallway sessions. But I’d like to provide some pointers to my favorite papers of the conference:

David Jeffery’s keynote on Betfair’s event driven architecture, past present and future. David presented not only on the performance challenges of running the core betting exchange, but also on the soft benefits. Thanks to their event driven architecture, Betfair is able to do more experimentation with less disruption, and be more agile as an organization.
Dan O’Keeffe presented Reliable Complex Event Detection for Pervasive Computing, a system for compensating for missing data. Most importantly, it lays out a selection of strategies that developers can select and the system can use to automatically choose the correct approach, based on wether the system should be optimistic, pessimistic, or something in between.
Quilt: A Patchwork of Multicast Regions was presented by one of the local students on short notice, because the author was not able to attend due to visa problems. This is especially frustrating when the paper is so interesting and the analysis quite strong. Quilt is a system for combining multiple delivery mechanisms to achieve efficient wide area distribution. Combining overlay-network based protocols with “patches” of true multicast where available, Quilt optimizes message routing for efficiency, reliability, and latency.
An Approach for Iterative Event Pattern Recommendation which was also presented by a colleague rather than one of the authors due to visa issues. The paper describes a system for recommending event patterns to domain experts based on their initial attempts to define the pattern. In a controlled user study, the recommendation system substantially reduced the time taken by users to define novel patterns. It was good to see a real user study of a programming efficiency system, but there is lots of room for further measurement.
Experiences with Codifying Event Processing Function Patterns, presented by the author Anand Ranganathan, dealt with a different kind of pattern. In systems using Ranganathan’s system, developers build template network flows, annotated with tags to define what components can be used in the flow. Any component that matches the inputs, outputs, and tags can be inserted into the template, and all possible template instantiations represent a domain of valid applications. End users are able to search this combinatorially large domain with a flexible interface, to find and instantiate applications that meet their needs.

There are many great papers and talks not listed here. Obviously my own bias shows, as does the fact that I didn’t attend every talk or read every paper.

Normal Accidents and Stock Market Crashes

Mon, 14 Jun 2010 11:31:00 +0000

In the weeks since the precipitous and brief stock market crash on May 6th, I have found myself answering questions about it from people outside the capital markets and discussing it with insiders on many occasions. While I have some thoughts about what went on, I’m often unable to satisfy people’s desire to blame a single precipitating cause. I think what is going on is that too few people understand the nature of complex systems and what is called a “normal accident.” Given the sophistication of the markets, the number of safety checks and balances, as well as the complexity of the implementations, it is not surprising that events such as May 6th happened, nor should people think it is possible to entirely eliminate them.

End of the World Insurance: the Financial Halting Problem

Sun, 02 May 2010 21:30:00 +0000

In computer science, the halting problem is very well known. The problem states that it is impossible to build a software program that can analyze other software programs to determine if they will eventually terminate, or halt. This is a useful problem to understand, because many software problems that look possible at first can be reduced to the halting problem and thus demonstrated to be impossible. It’s common to hear someone say “actually, that seems like a halting problem” when discussing compiler optimization, program analysis, and related problems in computer science. This is much like a physicist might say “but that’s perpetual motion.”

Synthetic Biology and Big Ball of Mud

Sun, 04 Apr 2010 23:25:00 +0000

Researchers at the MIT OpenWetWare project are attempting to engineer Synthetic Biology, creating reusable and composable biological components that can be combined to create useful organisms. In the process, they are discovering that biological systems don’t follow the same patterns of good architecture familiar to us from software.

In software engineering, architecture is perceived as critical to the success of a large implementation project, and also to the ongoing maintenance of the code created. Since software is very expensive, there is a lot of focus on architecture, choosing the right architecture, and making sure that the architecture is faithfully executed. Some of the biggest changes in software in the last 30 years, like object oriented programming and service oriented architecture, have come about because of a need for clearer architecture in ever larger collections of software that run modern life.

Project Euler, MIT Mystery Hunt Edition

Sun, 10 Jan 2010 23:52:00 +0000

The MIT Mystery Hunt starts this Friday at noon, and I’ll be participating seriously for about my 10th year. In the hunt, teams solve a collection of puzzles to discover the location of a gold coin hidden somewhere on campus. The puzzles may be numerous (sometimes over 100), are generally provided without instructions (except when they are provided with painfully explicit instructions), and the overall structure of the hunt is also unknown at the start. Hunt is nearly always finished before Monday, but during the 60 hours starting Friday at noon, many highly capable teams, some with several dozen members, will try their hardest to solve some very challenging puzzles.

Algorithms for the 21st Century

Thu, 28 Sep 2006 22:51:00 +0000

Went to a talk at MIT tonight, by Stephen C Johnson, a researcher at The Mathworks. The talk was sponsored by the Greater Boston ACM. The paper, Algorithms for the 21st Century, was presented at Usenix 2006. The general thrust was how computer architecture has drifted from the idealized model used in most algorithms classes, in significant ways. The major focus was on the memory subsystem, and how caching can effect algorithmic performance. By looking at the behavior of very simple algorithms, we can see fairly complex variations in performance, by factors as high as 60 times worse. This in turn implies that the performance of complex algorithms will be even more diffi
cult to characterize.
One big take-away is that the built-in cache management schemes of modern memory systems are pessimal for certain algorithms. This actually sounds quite a bit like the complaints against operating system disk buffer/virtual memory management by database authors. Database algorithms, because they often have large storage access requirements that can be characterized in advance, benefit from managing their own buffers. Similarly, it seems like scientific computing (eg, Matlab), which wants to manipulate gigabytes of memory in very structured ways, would benefit from direct management of caching. Of course, cache management needs to run at processor-speed, unlike disk buffer management, so writing heavyweight algorithms is inappropriate. Unfortunately, the talk did not discuss any recommendations for extentions to enable management. I wonder if something as simple as being able to mark a page as no-cache in the TLB would be sufficient.
My other take-away is that computer science researchers don’t understand computers nearly enough. The presenter, while familiar with processor design and memory architecture, wasn’t really able to explain the behavior of these simple algorithms in their entirety. I’m always bothered when I encounter this lack of understanding. On some level it seems that it should be possible to fully understand computer systems. After all, they are developed by humans, and to a first approximation their behavior is deterministic and well defined. Unfortunately, they change rapidly, and so any abstract models we develop are shortly invalidated. Fundamentally, this is what makes computer science difficult.