Monday, May 12, 2008

HPC Considered Harmful

I'm really looking forward to Greg Wilson's talk called "HPC Considered Harmful" at Scientific Software Days at TACC, for which I am a co-organizer. Also Eric Jones will be talking about "New Directions in Scientific Workflow" which sounds great too.

I'm not sure what these guys will say, but I think this (Carriero et al 2004) is relevant:
The goal of [our] approach is not to reap the maximum efficiency benefits in making changes to a program. Rather the goal is to remove compute time as a rate-limiting step.
Anyway, come on down if you're in the neighborhood!


Monday, May 5, 2008

Life in the Trenches, Generalized

A really good description of the problem is here.

It's only exacerbated when both the producers and the consumers of the software are scientists who don't think software principles are interesting and/or whose mentors don't believe in time for training on such principles. Invariably we are targetting weird platforms, too.

I recently heard someone say that about 30% of professional programmers' time is spent on build issues. If scientists are as much as half as good as full-timers, that means they spend 60% of their time on build issues, but they also have to spend 50% of their time on reading and writing discipline-related stuff. That means we get negative 10% of our time for actual productive coding. If we're lucky.

Monday, April 21, 2008

Sudden abstractions

verbatim from "Young Archimedes" by Aldous Huxley, 1928

(an English family spends a year in Italy and their young child befriends an older peasant boy)

"Though fully two and a half years older than little Robin - and at that age thirty months are crammed with half a lifetime's experience - Guido took no undue advantage of his superior intelligence and strength. I have never seen a child more patient, tolerant and non-tyrannical. He never laughed at Robin for his clumsy efforts to imitate his own prodigious feats; he did not tease or bully, but helped his small companion when he was in difficulties and explained when he could not understand. In return, Robin adored him, regarded him as a model and perfect Big Boy, and slavishly imitated him in every way he could.

"These attempts of Robin's to imitate his companion were often exceedingly ludicrous. For by an obscure psychological law, words and actions in themselves quite serious become comic as soon as they are copied; and the more accurately, if the imitation is a deliberate parody, the funnier - for an overloaded imitation of someone we know does not make us laugh so much as one that is almost indistinguishably like the original. The bad imitation is only ludicrous when it is a piece of sincere and earnest flattery that does not quite come off. Robin's imitations were mostly of this kind. His heroic and unsuccessful attempts to perform the feats of strength and skill, which Guido could do with ease, were exquisitely comic. And his careful, long-drawn imitations of Guido's habits and mannerisms were no less amusing. Most ludicrous of all, because most earnestly undertaken and most incongruous in the imitator, were Robin's impersonations of Guido in a pensive mood. Guido was a thoughtful child given to brooding and sudden abstractions. One would find him sitting in a corner by himself, chin in hand, elbow on knee, plunged, to all appearances in the profoundest meditation."

...

(Guido is discovered to have a gift for mathematics.)

"This child, I thought, has had the fortune to be born at a time when he will be able to make good use of his capacities. He will find the most elaborate analytical methods lying readily to his hand; he will have a prodigious experience behind him. Suppose he had been born while Stonehenge was building; he might have spent a lifetime discovering the rudiments, guessing darkly where he might have had a chance of proving. Born at the time of the Norman Conquest, he would have had to wrestle with all the preliminary difficulties created by an inadequate symbolism; it would have taken him long years, for example, to learn the art of dividing MMMCCCCLXXXVIII by MCMXIX. In five years, nowadays, he will learn what it took generations of Men to discover."

(Alas the story ends sadly for the fictitious young Guido, while happily for all of us in real life, the analogy breaks down. Clearly Guido should have contrived to be born not just in the modern age but also in Holland...)

Now let me think a minute, son


Ah, yes, that can be easily done...

Sunday, March 30, 2008

More Python and Climate

Apparently my rants got linked by GravityLoss, who understands that I am saying something about Python and about modern methodologies, but apparently isn't sure exactly what.

Here's my reply:

Hi and thanks for the links.

Make no mistake, I am a Python fanboy. I really doubt it's possible to do much better than Python at our present level of understanding of how to control computers.

As Paul Graham explains, any assertion that a more advanced technology Y is better than technology X tends to fall on deaf ears on users of technology X, because what they think is doable is defined by technology X. It is perfectly possible to get no advantage from Y because it is always possible to do X-like things with it.

I am proposing to do somewhat different things with Y. I am not the greatest expert on Y, but I do see things to do relevant things with Y that are not entirely X-like.

I would like to have software managers more experienced than myself involved. Google are the folk with the disposable wealth and the farsighted motivation as well as some of the relevant skills. I sort of wish they'd do what I want to do rather than leaving me scrambling to do it. I retain enough hubris to suggest that if they tried they'd do well to get me on the team. Realistically I probably will not have their help nor the help of an experienced software manager, though any pitching in from JM or JM would be most welcome.

There's nothing magic about Google or Python that aren't summed up in Clarke's Law: any sufficiently advanced technology is indistinguishable from magic. The sad thing is that much of the academy, including climate science, is far enough behind the cutting edge of what is possible that comparable productivity would look magical.

Friday, March 21, 2008

The elegance of Fortran

You know, the point of OOP is to SAVE work. 

Yes, the following is the most trivial and trite and pointless possible example of OOP.  I am not showing you code that is interesting. I am just comparing it with bolted-on OOP. Have a look at the Fortran equivalent. It's completely equivalent, note.

The "polymorphism" section form the Fortran is expressed in Python as an arbitrarily small amount of whitespace. And you thought whitespace was a drawback of Python!

def vectorsum(vec1,vec2):
...return map(sum,zip(vec1,vec2))

class Circle(object):
...def __init__(self,center,radius):
......self.center = center
......self.radius = radius

...def __str__(self):
......return "circle of radius %s at %s" % (self.radius, self.center)

...def move(self,translation):
......assert len(translation) == len(self.center)
......self.center = vectorsum(self.center, translation)

class Square(Circle):
...""" note: can inherit constructor for circle; treat radius as length"""
...def __str__(self):
......s = self.radius
......shifts = ((0,0),(0,s),(s,0),(s,s))
......corners = tuple([vectorsum(self.center,shift) for shift in shifts])
......return "square at points %s %s %s %s" % corners

Saturday, March 15, 2008

PyCon snippets

Stuff to look into:

iPy1: a spawned interpreter on every CPU

MPI4py: the winner for fine-grained parallelism

distributed NumPy array: Brian Granger

"it's like a beginner trying to make a souffle; you WILL get an egg dish"

stats.bayes.mvs

new buffer type in Py 3, Travis O in charge, imports NumPy arrays; PEP 3118

struct module

Amazon's elastic cloud; Pete Skomorock's ElastiWulf

Trestle

noonhat.com ; saturdayhouse.prg

pyxpcomext.com

freebase

argparse

orbited

math instruction in APL

if you want to start a conversation, ask a question