May 09, 2009

Elastic Shortfalls

Anybody reading this space knows I have been a huge fan of Obama and Geithner, but this week they lost me.

The way to recognize a project in trouble is not to ask for a single assessment - the way is to compare today's assessment to the one from a few weeks ago. A troubled project is elastic, stretching to absorb forever more amounts of time and money.

This week's SCAP results release revealed that our bank failures are elastic. Geithner is not doing a good job at calling the situation and driving the bank crisis to a close.

Continue reading "Elastic Shortfalls"
Posted by David at 10:47 PM | Comments (2)

May 22, 2009

Your Compiler Vanishes in A Puff of Logic

I can write a program in Java about twice as fast as as I can write the same program C or C++, and I can bang out the same program in Python maybe twice again as fast as I can in Java. In Python, you just get straight to the point and say what you mean by saying things like:

weekly = [sum(daily[j:j+7]) for j in range(0, len(daily), 7)]

In an ideal world, high-level languages like Python would replace all other programming languages.

In principle, a program written in a high-level language like Python should be able to execute faster than one written in a low-level language like C, because fewer of the implementation details are constrained by the programmer. The less the programmer says, the more flexibility the compiler has to speed things up. Of course, in reality high-level languages are much slower than low-level languages, so at Google we write most of our performance-sensitive code in C++. Even though we need to invest maybe four times as much effort.

But the PyPy guys have not given up the dream of fast high-level languages. They are making progress on an epic project to make python - and all interpreted languages - speedier than C. And they are doing it by sticking to their guns: instead of getting in the dirt and implementing a pile of low-level tricks, they are raising the level of abstraction to ever higher heights, writing their compiler, interpreters, profilers and jitters all in highly abstract python, and then applying the compiler to itself to make the final product.

Along the way, they have only needed to resort to one or two easily-explained dirty tricks.

PyPy's progress on a tracing JIT for a python meta-interpreter are documented in a paper by Bolz, Cuni, Fijalkowski, and Rigo. If you are into language technology, it is well worth a read. Their project is akin to engineers who dare to build a ladder to the moon. It seems improbable, but once they do it, it will change the world.

Someday we will all program in python.

Posted by David at 07:26 PM | Comments (14)