Hacker News Reader

Comment by sitkack | Hacker News Reader

I don't know why people are leaving Python for Go when they could be using PyPy or Shedskin. There are plenty of ways to be fast using Python.

View on HN

Visibility probably. Every whiner blogs "I'm leaving Python for Go" but that was the first time I saw https://code.google.com/p/shedskin/ mentioned.

I think Christian derived people have a tendency to seek solutions as an externality. Rather than focus on the root cause of something and transcend it, we destroy and recreate using a different raw material. Hence leaving Python for X and not realizing that the pattern, leaving <thing> for <replacement>, will continually have one in a cycle of stagnating reconstruction.

If Python is slow, we are using it wrong.

It's easy to lose track of this in the torrent of "PyPy Benchmarks Show It Sped Up 2x!!!!" and "Latest Javascript Engine 50% Faster Than The Last One!!!! OMG!! Node!!!!", but in absolute terms, the dynamic language JITs are still quite slow. It's an urban legend that they are anywhere near compiled performance. Except LuaJIT. "Faster Python" is still slow. Unless you're in a tight loop adding numbers together, but I'm not.

Moreover, a plot of their performance over time rather strongly suggests that they've plateaued. Personally, barring any major JIT advances, I'm considering the book closed on the topic of whether JITs can take a dynamic language and make it as fast as C or C++: No.

(Recall that a Java JIT is another issue; it starts with the static typing of Java, and then JITs from there. It has a much larger array of much more powerful guarantees to work with, that the dynamic languages simply don't. Go will be running at straight-up C speeds (which it does not currently) long before Python will.)

Personally, barring any major JIT advances, I'm considering the book closed on the topic of whether JITs can take a dynamic language and make it as fast as C or C++.

It's possible to close more of the speed gap, but these JITs have to be able to:

* identify and use native primitives (avoid overflow and so forth)

* prefer stack allocation over heap (improved escape analysis)

* inline memory allocation and freeing and remove unused codepaths

* optimize across the boundary between implementation language and hosted language (which I believe requires self-hosting)

I think you're fundamentally confused about how computers work. It is always faster to do things in software than in hardware. Naive optimizations are always faster than data flow analysis from profiling. More layers of indirection make things faster, so the fastest languages put interpreters inside of their interpreters. War is peace. Slavery is freedom. The kids are getting smarter.

Why the heck are you posting stuff on this hell hole? Why am I posting stuff?

Procrastinating writing a JIT? http://dynamorio.org/

JITs are/can be faster than static code. They can make dynamic and data dependent optimizations not possible any other way.

Reply on news.ycombinator.com