That was a straw man (sorry). There's also the overhead of maintaining consistency, synchronizing metadata, etc. I don't think assuming 0.1% CPU overhead for Lustre is a terrible estimate, but even if it were much lower, the argument would still hold (at least at the scale of Titan).
There are a couple of (related) reasons. The first thing to recognize is that systems such as this one are designed for parallel workloads where all processes are running in lockstep, communicating via MPI with frequent barriers. This is very different from MapReduce and other asynchronous or "embarrassingly parallel" workloads where GFS, HDFS, etc. tend to be used. Distributed filesystems used in high-performance computing (such as Lustre, IBM's GPFS, etc.) also have to be able to handle both reads and writes with high throughput, whereas GFS is mostly optimized for reads and appends.
Why not just install disks in the compute nodes and run Lustre there? Since all the nodes are working together in lockstep, system jitter is a major problem. Imagine that you have a job running across 10,000 nodes and 160,000 cores, and a process on one of those cores get preempted for a millisecond while a disk I/O request is being serviced. Everyone waits, and you've suddenly wasted 160 core-seconds. Now, if this happens only 1000 times per second across the whole machine, it's clear that you're not going to make much forward progress, and the whole system is going to run at very low efficiency. For this reason, Crays and similar large machines run a very minimal OS on the compute nodes (a linux-based "compute node kernel" in the case of Cray). Introducing local disks would go against the whole philosophy.
There's also the issue of network contention. The network is typically the bottleneck, and you want to minimize the extent to which file I/O competes with your MPI traffic.
As someone else mentioned, the solution is to have a dedicated storage system (often Lustre running on a semi-segregated cluster). This approach is used almost universally by the 500 systems on the Top 500 list (http://top500.org), for example. It's not just inertia :-).
As an author of that paper, I can tell you that the code generator was rather simple and mainly used to perform loop unrolling, avoid explicit indexing, and replicate bits of code that couldn't quite be encapsulated in inline functions. It's possible to go further, but this sort of metaprogramming doesn't really eliminate the need to write in CUDA C.
For what it's worth, we long ago abandoned scala in favor of python for the code generator, just to make it more accessible to others interested in working on the project (generally particle physicists by training): http://lattice.github.com/quda/
Of the responses so far, this one is closest to being correct. Rather than "asymptotically approaching zero," however, the height of the bounce will quickly converge precisely to zero. Assume that the previous bounce (up and back down) took time t. Then the ball will stop bouncing after time t/(1-sqrt(0.6)) ~ 4.4t. After that, the ball will simply continue moving ("rolling") to the right. This follows from summing the geometric series 1 + sqrt(0.6) + sqrt(0.6)^2 + sqrt(0.6)^3 + . . . , where 0.6 = (1 - 0.4) is the ratio of the height of the next bounce to the current bounce, and we take the square root since height and time are related by h = 1/2 at^2.
Incidentally, for anyone who has a ping pong ball handy, this is very close to what happens in real life.
Edit: To clarify, it's the parent's "old, wrong answer" that's closer to being correct. btilly (below) also has it right.
I'm getting the same thing, which isn't surprising since I'm using Opera. In general, I think it's fine to say "browser not supported" if that's the case, but it's nice to have a "Try anyway" link. There are too many sites that work fine with a given browser but refuse the user a chance to try. If you give the user a choice, the worst case is that the site really is broken with their browser, and they say "Hmpf, guess they're right" and move on.
I suppose there's a potentially worse case where the site is broken in some subtle way that causes data corruption or the like, but I can't imagine there are many webapps where this is a serious concern.
Things haven't changed much. I grew up in Trafford (it's not often I can expect someone to know where that is) and inevitably find myself at Monroeville Mall every year during the holidays.
It's coauthored by a pediatrician, so the recommendations are evidence-based, but it's also practical and relatively concise.
[Disclaimer: The edition I read was published over a decade ago, but the latest edition doesn't appear to be radically different.]