Hacker News Reader

Comment by _halgari | Hacker News Reader

I'd love to hear more about their issues with PyPy, it sounds like they wrote of PyPy simply because they don't understand why it works so well. Not to mention that this is mostly a re-hash of stuff found in unladen-swallow.

I mean, if your end goal is to write another Python, sure go for it. But it really sounds like these people haven't done their research. I see nothing to write home about.

--- EDIT ---

Not to mention that JS is a completely different language form Python. Everytime you add two objects in Python you have the possibility of hitting a system defined add, or __add__ or __getattr__ or __getattribute__, or __radd__, or __getattr__ (looking for __radd__), etc. That'll be fun....

View on HN

Their description does not suggest they don't understand how PyPy works, but rather they don't think they can tackle the yet unsolved failure modes (blowup, etc) of trace compilation.

They approach they're describing is one that already works in V8, JScore, and IonMonkey, which is to mix type prediction, type analysis, and runtime handling of unexpected cases. Basically, you use type feedback information to get an initial set of types for a method, use type inference techniques to squeeze out type checks, and then compile the method in a way that handles the expected types in a fast path and traps into a slow path as necessary.

None of V8, JavaScriptCore, SpiderMonkey do allocation removal, which is the single most important optimization PyPy and LuaJIT do, which also goes back to Psyco. I think it is unknown how to do this well in method JITs.

Allocation removal by partial evaluation in a tracing JIT: http://dl.acm.org/citation.cfm?id=1929508

Allocation Sinking Optimization: http://wiki.luajit.org/Allocation-Sinking-Optimization

Yet V8, etc, perform pretty well. Is there a reason to believe allocation removal is particularly more important for Python than JS? It might be, I haven't thought about it, but at first blush that doesn't seem to be the case.

> None of V8 .. do allocation removal

This is not correct. V8 does sink allocations into deoptimization exits. It does not sink allocations out of the loops at the moment though.

> I think it is unknown how to do this well in method JITs

I don't think it is unknown. The main simplification for tracing JITs comes from the fact that deoptimization and loop-exit can be elegantly treated within the uniform framework, which is a little bit harder for method JIT and you need to find right place to insert materialization instruction after the loop based on post-domination. Nothing hard or unsolvable though.

It seems like there are a couple topics that come up when talking to people about switching to PyPy: - performance or memory usage on larger programs - C extension module support I'm not going to promise that we will do a better job at these, but there are technical reasons to think that it's possible.

You're definitely right, Python has a lot of user-customizability that can make it harder to execute efficiently than JavaScript (though thankfully it has less than Ruby). Both PyPy and Pyston have their techniques for cutting through the complicated+expensive slow case and trying to predict and execute a fast path.

Just to be perfectly clear: it's 100% possible to write an efficient Ruby implementation, and if you have the right technical infrastructure, it's no more difficult than Python, or Javascript for that matter.

"Everytime you add two objects in Python you have the possibility of hitting a system defined add, or __add__ or __getattr__ or __getattribute__, or __radd__, or __getattr__ (looking for __radd__), etc"

That's pretty much a solved problem. Lookup the method once, cache it for next time, deoptimize if you're wrong or the definition of the class changes. If it keeps changing build up a larger cache.

Ruby has exactly the same behaviour, and we can still get it down to really simple machine code http://www.chrisseaton.com/rubytruffle/how-method-dispatch-w....

Every time you add two objects in JS you have the possibility of hitting toString at least; every time you access a property it might be a getter or setter, or a Harmony proxy object. Python is more liberal, but in both cases you have to make guesses about object shapes (and objects not having those properties) to have any hope of performance.

But considering GvR works for Dropbox and tweeted this out a few minutes back, they do have his backing.

Reply on news.ycombinator.com