What Do Linux Developers Say in Commit Messages?

I was curious what different people worked on in Linux, so I tried grabbing data from the current git repository to see if I could pull that out of commit message data. This doesn’t include history from before they switched to git, so it only goes back to 2005, but that’s still a decent chunk of history.

Here’s a list of the most commonly used words (in commit messages), by the top four most frequent committers, with users ordered by number of commits.

Given That We Aren’t Going to Put Any Effort Into Testing, What’s the Best Way to Test?

Everything is broken. But I often get skepticism when I mention that I run into multiple new (to me) bugs per day, and that this is inevitable if we don’t change how we write tests. Well, here’s a log of one week of bugs. After a brief description of the bugs, I’ll talk about what we can do to improve the situation. The obvious answer to spend more effort on testing, but everyone already knows we should do that and no one does it. That doesn’t mean it’s hopeless, though.

One week of bugs

Julia

Unicode sequence causes match/ismatch to blow up with a bounds error.

Unicode sequence causes using string as a hash index to blow up with a bounds error.

Exception randomly not caught by catch. This sucks because putting things in a try/catch was the workaround for the two bugs above. I’ve seen other variants of this before; it’s possible this shouldn’t count as a new bug because it might be the same root cause as some bug I’ve already seen.

Speeding Up Octopress by 15x

I’ve seen all these studies that show how a 100ms improvement in page load time has a significant effect on page views, conversion rate, etc., but I’d never actually tried to optimize my site. This blog is a static Octopress site, hosted on Github Pages. Static sites are supposed to be fast, and Github Pages uses Fastly, which is supposed to be fast, so everything should be fast, right?

Not having done this before, I didn’t know what to do. But in a great talk on how the internet works, Dan Espeset suggested trying webpagetest; let’s give it a shot.

What Are the Odds the Build Actually Works?

I’ve noticed that builds are broken and tests fail a lot more often on open source projects than on “work” projects. I wasn’t sure how much of that was my perception vs. reality, so I grabbed the travis CI data for a few popular categories on github1.

The Empirical Evidence That Types Affect Productivity and Correctness

There are some pretty strong statements about types floating around out there; for the most part, those claims haven’t matched my personal experience. The claims range from the oft-repeated phrase that when you get the types to line up, everything just works, to “not relying on type safety is unethical (if you have an SLA)”1. There are probably plenty of strong claims about dynamic languages that I’d disagree with if I heard them, but I’m not in the right communities to hear the more outlandish claims about dynamically typed languages. Either way, it’s rare to see people cite actual evidence.

This is a review of the empirical evidence.

Why Intel Is Adding Instructions to Speed Up Non-volatile Memory

The latest verison of the Intel manual has a couple of new instructions for non-volatile storage, like SSDs. What’s that about?

Before we look at the instructions in detail, let’s take a look at the issues that exist with super fast NVRAM. One problem is that next generation storage technologies will be fast enough that syscall and other OS overhead can be more expensive than the actual cost of the disk access1. Another is the impedence mismatch between the x86 memory hierarchy and persistent memory. In both cases, it’s basically an Amdahl’s law problem, where one component has improved so much that other components have to improve to keep up.

Cache Eviction: When Are Randomized Algorithms Better Than LRU?

Once upon a time, my computer architecture professor mentioned that using a random eviction policy for caches really isn’t so bad. That random eviction isn’t bad can be surprising – if your cache fills up and you have to get rid of something, choosing the least recently used (LRU) is an obvious choice, since you’re more likely to use something if you’ve used it recently. If you have a tight loop, LRU is going to be perfect as long as the loop fits in cache, but it’s going to cause a miss every time if the loop doesn’t fit. A random eviction policy degrades gracefully as the loop gets too big.

In practice, on real workloads, random tends to do worse than other algorithms. But what if we take two random choices and just use LRU between those two choices?

Here are the relative miss rates we get for SPEC CPU1 with a Sandy Bridge-like cache (8-way associative, 64k, 256k, and 2MB L1, L2, and L3 caches, respectively). These are ratios (algorithm miss rate : random miss rate); lower is better. Each cache uses the same policy at all levels of the cache.

Policy L1 (64k) L2 (256k) L3 (2MB)
2-random 0.91 0.93 0.95
FIFO 0.96 0.97 1.02
LRU 0.90 0.90 0.97
random 1.00 1.00 1.00

API Design as if Humans Actually Mattered

This is a read along for Hacker School’s paper of the week series for The Chubby Lock Service for Loosely-Coupled Distributed Systems.

This is one of my favorite papers! A lot of their decisions were made so that their service would be useful for humans, as opposed to for some technical reason. The entire reason they built a lock service instead of a library was so that it would be easy to use, and you can see that thinking reflected at multiple levels.

Hand Coded Assembly Beats Intrinsics in Speed and Simplicity

Every once in a while, I hear how intrinsics have improved enough that it’s safe to use them for high performance code. That would be nice. The promise of intrinsics is that you can write optimized code by calling out to functions (intrinsics) that correspond to particular assembly instructions. Since intrinsics act like normal functions, they can be cross platform. And since your compiler has access to more computational power than your brain, as well as a detailed model of every CPU, the compiler should be able to do a better job of micro-optimizations. Despite decade old claims that intrinsics can make your life easier, it never seems to work out.

The last time I tried intrinsics was around 2007; for more on why they were hopeless then (see this exploration by the author of VirtualDub). I gave them another shot recently, and while they’ve improved, they’re still not worth the effort. The problem is that intrinsics are so unreliable that you have to manually check the result on every platform and every compiler you expect your code to be run on, and then tweak the intrinsics until you get a reasonable result. That’s more work than just writing the assembly by hand. If you don’t check the results by hand, it’s easy to get bad results.