Hacker News Reader

Comment by krob | Hacker News Reader

The concept is cool, but I think that once all the tokenization is done on the full construct of the language, it probably won't be substantially that much faster than hiphop C++ converter. This is only a 1.0 with benchmarks based on limited functionality. As the code-base grows, so will the pains to optimize the speed.

View on HN

I disagree. Have you seen the benchmarks where they showed Python code in pypy running faster than C equivalents? Sure they were contrived, but they support the idea that theoretically any JIT runtime should be faster than ahead-of-time compilation. It makes sense to me, since the JIT runtime has more information with which to optimize the code - pypy knows what's going on with the code while it's executing, whereas the hiphop compiler only has information about the code itself.

In addition, an implementation in pypy should be able to support eval, which is impossible (or perhaps extremely difficult) with hiphop.

They were far from all contrived: many were taken from bottlenecks in real Python applications. Off-hand, at least the django, genshi, and html5lib benchmarks are very much real code, and none of the three benchmarks are optimized for PyPy in any way.

Yes, running Django in pypy gives you enormous speed boosts (I've seen it myself), but that's not what I was talking about.

I was referring to the benchmarks in which they measured Python code in pypy running against pure C code (see some examples below). While I'm not familiar with the benchmarks you're referring to, I doubt anybody implemented all (or even parts) of Django, genshi or html5lib in C.

http://morepypy.blogspot.com/2011/02/pypy-faster-than-c-on-c... http://morepypy.blogspot.com/2011/08/pypy-is-faster-than-c-a...

See http://speed.pypy.org/ for the benchmarks I was referring to: that's the general collection of benchmarks used for PyPy (several, such as the html5lib one, imported from unladen-swallow), though obviously in specific cases comparisons are made otherwise.

It sounds like he prepared for that: "get as close to PHP as possible, implementing enough warts and corner cases to be reasonably sure that it answers hard problems in the PHP language"

Reply on news.ycombinator.com