I thought he was talking about the 70x result, not the 1 billion result. Quoting from the 70x benchmark:

For this test, 3 machines were used:

Intel Core 2 Quad Core @2.83 GHz; 8 Gbytes RAM; single, multi-threaded data node (ndbmtd)
Intel Core 2 Quad Core @2.83 GHz; 8 Gbytes RAM; single, multi-threaded data node (ndbmtd)
4 Core Fedora VM running on VirtualBox on Windows 7, single MySQL Server

It looks like the AQL feature has pushed work from that MySQL-on-VirtualBox-on-Windows-7 system to the pair of data nodes with 8 GB RAM, and found it runs 70x faster. It doesn't say how much RAM the MySQL server had, what the data nodes were running, or why it was running in that virtualized environment in the first place. I can't say I'm surprised that offloading work from such a place has has provided a big win. It may be more interesting to see the result from a more typical setup, such as MySQL running on a baremetal OS.

This depends on the lunar regolith deposition rate, which I've seen quoted as 1 cm per 2-3 million years. Imagine Tranquility Base - which has over 100 man made artifacts on the surface (http://spacegrant.nmsu.edu/lunarlegacies/artifactlist.html) - in one million years from now, with half a centimeter of dust. This makes the lunar surface a time capsule of past activity (provided the site doesn't get wiped out by an asteroid impact), in a way that the Earth isn't. We've yet to photograph the surface at high enough resolution to really know what's there.

This is a great technology story - even if only for one version of Linux so far. DTrace will bring tremendous value for troubleshooting and performance analysis, and is a technology I use (almost) every day.

For example, yesterday I had a CPU bound workload with an unexpected level of variation, and used DTrace to measure the effect of CPU thread affinity and interrupt activity on that workload. I used DTrace to pull the runtime along with other details: number of scheduling events for that thread, along with the CPUs that the thread ran on; also, for preemption, the pre-emptor thread (to see why) along with both its user-level and kernel stack traces; also the interrupt thread and device. I fairly quickly showed that the runtime variation was caused by network interface interrupts from an entirely different application. This analysis would take quite a lot longer without DTrace, and may be prohibitively difficult to complete.

Many of my uses of DTrace are much more straightforward than that; including identifying file system latency for applications, application response time, and CPU dispatcher queue latency. I've listed many more examples in the DTrace book (http://www.dtracebook.com). It should be a great resource of ideas for those looking to use DTrace on Linux - since the hardest part for people has been knowing where to start, given the ability to see everything.

Yes, it's annoying - every time we examine the system we are now looking at everything except for iTunes (and possibly Spy-WaR3 ;-). But this issue is about more than just that.

I've introduced DTrace to many companies. While most people love it, some developers of closed source software are concerned about people DTracing their code. DTrace allows customers to gather proof of bugs that are embarrassing, hard to fix, or that the developers have deny existed. I've been asked many times if DTrace can be disabled for an application, usually to avoid negative publicity from the bugs that DTrace will expose. The answer has always been no. It's been great to see developers accept this reality and escelate bug fixing.

This is expected - DTrace visibility should improve overall code quality in IT. Hopefully it will also encourage employers to hire better programmers - since if customers don't use DTrace to point out embarassing bugs, then competitors may. It also erodes reasons to stay closed source - customers can use DTrace to see the code anyway.

Giving developers another option, to disable DTrace visibility, is allowing a backwards step from the future.