The architecture for the Intel 48-core Single Chip Cloud Computer (SCC) processor is “arbitrarily scalable,” said Intel researcher Timothy Mattson, during a talk at the Supercomputer 2010 conference being held this week in New Orleans.

“This is an architecture that could, in principle, scale to 1,000 cores,” he said. ” I can just keep adding, adding, adding cores.”

…

For simplicity’s sake, the team used an off-the-shelf 1994-era Pentium processor design for the cores themselves. “Performance on this chip is not interesting,” Mattson said. It uses a standard x86 instruction set.

And so the message of the prophets of functional programming is ratified in part. It’s been a meme in the past several years that radically multicore processors were coming, and that the received models of concurrent programming were unlikely to do a good job utilizing the new hardware. That hardware would be slower (or at best no faster) per processor, but would instead grow the number of processors to deliver more computing power over time. And now that radical multicore is appearing, what of the claim that threading and synchronized mutable data is a dead letter? Well, ask a hardware guy:

As more cores are added to chips, [cache coherency] becomes problematic insofar as “the protocol overhead per core grows with the number of cores, leading to a ‘coherency wall’ beyond which the overhead exceeds the value of adding cores,” the paper accompanying [Intel researcher Timothy] Mattson’s talk noted.

Mattson has argued that a better approach would be to eliminate cache coherency and instead allow cores to pass messages among one another.

Interesting that hardware designers have made the same discovery that we have: to wit, that managing concurrent access to mutable state is simply not possible at scale. We often make the argument as a cognitive one—that programmers simply can’t reason effectively about heavily threaded and synchronized code—but there turns out to be a performance boundary as well.

A 1,000-core part is an automatic win if you’re writing server software whose unit of work is a computationally mundane request. You parse some text, you do some disk or socket I/O, you sort some lists, you process strings into an output buffer, and nobody gets hurt. But if your computational task is less mundane and actually requires thoughtful coordination of computing resources that doesn’t delegate well to infrastructure like an app server, then trying to manage mutable state by hand will wreck you on the same rocks as Intel’s hardware designers.

Which is not to endorse, say, actors over STM, simply because the hardware in question looks more like one than the other. But it is to say that the prophets of mutability doom are not to be ignored, and you should probably start learning new languages as if you believed them.

The article explores several common Agile practices—to wit: user stories, lightweight documentation, and iterations—that happen to align well with normal human behavior given the kinds of creatures that we are. There is, you might be thinking, a host of philosophical assumptions that underlie this sort of reasoning, which I would be only too pleased to discuss over drinks sometime if you’re local.

I had to pick a limited number of Agile practices for analysis in the article, but I think there is more to the story than the three I’ve identified. A good example would be Extreme Programming’s Sustainable Pace. The opposite of Sustainable Pace is the discipline of death-marching developers just hard enough that they don’t quit, but hard enough that we squeeze maximum productivity out of them. If developers were impersonal units of software production akin to machines, this would be the right way to manage them.

The most obvious objection to this is the law of diminishing returns, or the idea that each marginal hour worked is an increasingly fatigued, and correspondingly less productive, hour. While there is certainly some truth to this, I think we’re forced to grant that we actually do make more progress when we work more hours. Everybody knows crunch time, and every honest developer is forced to admit that the crazy schedule of the final push to the finish actually make a difference—at least up until the time the hallucinations start, which in itself can be kind of fun, as long as it’s your coworkers doing the hallucinating.

The best objection to overwork isn’t a utilitarian one; rather, I would argue that the notion of Sustainable Pace is grounded in the right relationship between work and the other activities in human life given the kinds of creatures that human beings are. It is good and right for us to spend a certain amount of our time following some kind of economically productive vocation out in the commonwealth. It is also good and right for us to spend some amount of time with friends or family, some amount of time sleeping and eating, some amount of time standing in line at the DMV, some amount of time inside, some amount of time out-of-doors, etc. For most people, work might take up a plurality of the pie, but it should not be a significant majority. It is in our nature to spend our time in a variety of roles activities, of which work is but one part.

“The Humanity of Sustainable Pace” could definitely use a more detailed treatment than I’ve given it here, but my point is to illustrate that there is more to the topic than my article covers. I’d love to see the community do some more thinking along these lines. The trick is to realize that human beings are a particular kind of thing—we implement a common base class, if you will—so the practices and methods we develop in our vocation should respect that class’s semantics. The notion that we are uniform production units that can be squeezed into whatever organizational structure and management schema we choose is destructive not just to the ontology of the human person, but also to the well-being of the people on our teams—people who may well be our friends, and people whose healthy vocational context is certainly our responsibility.

So let’s think some more along these lines. Agile is doing great things, and hopefully more great ideas can follow from it.