rbabich

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.]

Yep: http://blogs.nvidia.com/blog/2014/06/23/two-steps-adobe-illu...

http://www.informationweek.com/oracle-buys-data-mining-techn...

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 :-).

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/

See also: http://en.wikipedia.org/wiki/Zenos_paradox (Hint: It's not really a paradox.)

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.

   volatile int i=1;
   while (i) { }

http://www.charitywatch.org/toprated.html#humanserv

Of course, this has a lot to do with economies of scale, and "low overhead" does not immediately imply "high impact per dollar."

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.