Although Grumpy is compiled, it is just as dynamic as Python, in that method dispatch involves dictionary lookups, etc.

The main reason why Grumpy's slower for most single threaded benchmarks is that most Python workloads involve creating and freeing a bunch of small Python objects. In Go, these objects are garbage that need to be GC'd in a very general way. In CPython, there are free lists, arenas and other optimizations for allocating small (especially immutable) objects. And cleaning up garbage in CPython involves pushing unreferenced objects back onto the free lists for later reuse.

> Although Grumpy is compiled, it is just as dynamic as Python, in that method dispatch involves dictionary lookups, etc.

Right, I suppose I assumed that straightforward numerical-looking code would be translated to Go numerical code. Perhaps they just aren't that ambitious yet.

We hope to implement optimizations like you're describing eventually. But the core functionality needs a lot of work before we start down that path.

Guido insists that single threaded performance of Python has the highest priority - http://www.artima.com/weblogs/viewpost.jsp?thread=214235

I am not sure, any implementation of Python will beat the single threaded performance of Cpython..

CPython is still a naïve interpreter. PyPy beats it in most cases, sometimes by a lot. Of course, PyPy still has a GIL for the same reasons CPython does.

So your complaint is that GVR doesn't want patches that would (significantly) regress performance for the majority of use cases, yes?

IIRC, IronPython single-threaded performance was competitive with CPython.

Multiple ones already do.

From the post it looks like it is optimized for multithreading from the start, so they possibly used the multithreaded version with thread count = 1. When you care for parallel workloads its not so important if your single-threaded code is the fastest.