See the PyPy JIT In Action

derGoldstein writes "Project PyPy is an alternative implementation of Python, with the main advantage being a Just In Time (JIT) compiler which speeds up your code considerably. They've announced the first public release of jitviewer, which is a visualization tool that helps you understand how your code is being compiled by PyPy's JIT, all the way down to assembly. If you just want to see how it looks and play with it, they've set up an online demo — just select a file, and click 'Show Assembler.'"

Comments

Go Pypy!

[Anonymous Coward]

I love python, and pypy makes dream about the day python could be used for anything, making java irrelevant.
The language is readable, flexible, succinct, expressive and beautiful.
Programming in python is more a joy than a core, but it has always suffered from a wide performance gap in cpu intensive tasks compared to traditional static languages.
Hopefully, this is all about to change with projects like this.
It's worth noting that Pypy is more than just an alternative python implementation. It is a framework for implementing jitted compiled dynamic languages.
There are currently several works in progress with implementations of javascript, scheme, logo, php and other languages with pypy.

Re:Go Pypy!

[H0p313ss]

The language is readable, flexible, succinct, expressive and beautiful.

I hear it cures cancer too. Oh wait, that's Ruby. (Actually, I love Python, but I'm allergic to fanboism...)

Re:Go Pypy!

[Anonymous Coward]

Python is not going to make Java irrelevant. Sorry. I know it hurts to be told that your religion will never become universal, but that's reality for you.

Certainly one reason for choosing Java over Python today is performance. Python is relatively slow, and sometimes throwing more hardware at the problem is not an option, and rewriting stuff in C (like Python fanboys always suggest) is not actually that easy (and brings with it all the problems of writing anything in C -- there's a reason we want to use Python or Java in the first place, right?)

But performance is only one of the reasons. The kinds of organization that choose Java appreciate a number of things it provides that Python, by design, will never provide. Such as static guarantees of any sort, or the ability to enforce the separation of public/private APIs rather than relying on "convention". (No, Python fanboys, reflection in Java does not subvert all access checks.)

There are entire classes of Python bug that are simply impossible in Java. Passing the wrong object type as a parameter. Accessing a non-existent variable because you made a typo in the name, or because you forgot that Python does not have lexical scoping. And so on. If your developers are not all the most brilliant hackers in the world -- as is the case in most Java shops -- these things are problems with Python. (No, fanboys, unit testing is not a substitute for type-checking and variable declarations. Hint: if your developers are not wonderful developers, they probably aren't wonderful test writers either.)

Python is great for small-scale projects or for enthusiasts, and it can be used for large-scale projects where you have a small team of highly-skilled developers, but those are not the markets Java is used in, and performance is not the primary reason why Java is used in those markets. After all, if all they cared about was performance, they'd use C++.

Re:Go Pypy!

[buchner.johannes]

The whole Java *or* Python discussion is irrelevant. You can use Jython, and take advantage of all the Python and Java libraries.

Re:Go Pypy!

[OeLeWaPpErKe]

You're argument only makes sense if you accept that the python language design requires dynamic typing. And this may (may) be true for the really advanced and esoteric uses of python, but anyone who's ever built a tiny compiler knows that 95% of python can easily be implemented statically typed. It would be a great exercise to try to fully inline the entire python runtime library to cover the remaining 5%.

Personally I'm convinced that a statically typed python supporting 90% of common use cases, and the IDE and tools that are possible to build using such a language would blow the regular python out of the water. Python's "dynamic" typing is in reality no more powerful than inference + splitting (ie. if you do 'x = 5; print x + 1; x = "boe"; print x + "1";' translate to 'x = 5; print x + 1; y = "boe"; print y + "1"', and split the variable name when re-typing occurs). And is there anyone here claiming that java's ctrl+space wouldn't be a great help in writing library intensive python code, never mind all other refactorings ?

I may understand in practice why people use dynamically typed languages, but theoretically there is no good reason for using dynamic typing at all. Furthermore python's "garbage collector" is so extremely basic it could simply be moved to compile time (I mean that there is no theoretical problem predicting all allocations of a python program at compile time, so (if you had a year to get this right) you could make python object allocation compile to a nop.

Re:Go Pypy!

[Tumbleweed]

I hear it cures cancer too. Oh wait, that's Ruby. (Actually, I love Python, but I'm allergic to fanboism...)

While it's true that Ruby cures (certain types of) cancer, it also has the unfortunate side effect of causing autism. Don't believe me? Try reading non-Ruby code written by Ruby fans.

Re:Go Pypy!

[ThePhilips]

[...] and rewriting stuff in C (like Python fanboys always suggest) is not actually that easy (and brings with it all the problems of writing anything in C -- there's a reason we want to use Python or Java in the first place, right?)

Actually, dismissing writing parts in C is not so simple. The only problem I'm aware of is the portability. And even that is handled by package/module management automatically.

Otherwise, most problem-free C programming I ever done (as C stuff goes) was Perl XS (*). Because you can leave to Perl all the mundane tasks and implement in C only the most performance-critical parts, which often have well defined input and well defined output. Even memory allocation stops being a problem: the objects one allocates in Perl XS come from Perl's GCed pool and managed automatically.

But of course, I'm not disagreeing with you in general: in Python, there are way too many cases where performance is simply unacceptable and everytime dropping into C would be a nightmare for a project of any scale.

(*) Learning Perl XS was a bitch, but I heard Python has much much more straight forward and well documented C interface.

The kinds of organization that choose Java appreciate a number of things it provides that Python, by design, will never provide.

The "number of things" are actually much more trivial this days and is not related to technical side of things: it is the pool of cheap workforce (out-sourceable too) which keeps most organizations addicted to Java.

and performance is not the primary reason why Java is used in those markets.

It is not the primary reason, but performance played its role in Java adoption. Recall why its predecessor Smalltalk never caught up: because it was dog slow and resource hungry.

Re:Go Pypy!

[Requiem18th]

Javascript is not a nice language, it's the unholy chimera of Self and Java.

Sure it's better than how most people describe it, but there are far better languages out there.

And by see you mean

[Anonymous Coward]

the connection has timed out

Python, the new Java

Woo hoo!

[93 Escort Wagon]

I'm glad to see it scales well!

Re:LLVM?

[rg3]

No, that was Unladen Swallow.

Re:The difference between Python and Ruby devs.

[Anonymous Coward]

I'm a python fan, but I think you are being a little bit unfair with the ruby community.
Python simply has more people working on making it fast (the pypy project started 8 years ago, and only recently it started to deliver on its promises).
By the way, pypy is a framework for creating jitted dynamic languages (it's written in python, but can be used to implement any other language).
So chances are that soon, someone will write a Ruby implementation with pypy, and this ruby vm will enjoy all the performance of the python one, because it will have an automatically created just-in-time compiler.

Quora

[Anonymous Coward]

quora.com is now running on PyPy.

http://www.quora.com/Alex-Gaynor/Quora-product/Quora-is-now-running-on-PyPy

Faster than C?

[lee1]

Not just faster than CPython, but faster than C for some common tasks. Pretty amazing.

However, this project is not yet very useful to the people who might be most interested in a really fast python, as it does not work with numpy. But when they get that to work, wow.

PyPy solves a very hard problem, but is still slow

[Animats]

It's an impressive effort that they were able to get this to work at all. Python is really tough to optimize. All bindings are changeable at any time, even from another thread. (The latter is silly, but since it doesn't cost anything to do that in CPython, which is an inefficient naive interpreter that can only run one thread at a time and spends much of its time doing dictionary lookups. Von Rossum defines the language by what CPython can do. There's a huge speed penalty for allowing such extreme dynamism, about 60x over C/C++. The Google team tried to fix that with Unladen Swallow, but gave up when their JIT system was barely faster than CPython.)

PyPy's most effective optimization to date is that it figures out when numbers don't have to be boxed. This allows generating numeric machine code, rather than grinding through the object machinery for every number. They have to be prepared to discard code when something binding gets changed. This requires a very complex system, involving two interpreters (regular and backup) as well as the JIT compiler.

The PyPy crowd is at last starting on the tougher optimizations, like hoisting some operations out of loops. (FORTRAN compilers were doing this in the 1960s.) That's real progress, but it's very hard to do in such a dynamic language.

Many of the optimizations involve generating run-time code that checks to see if the normal case is occurring, and that no other code has patched the code or changed the data from the outside in a way that invalidates the fast path. Then there's code to unwind what the fast path was doing, and interpret or recompile. Most such code is never executed.

Re:Another example of Open Source showing immaturi

[JonySuede]

sorry for the accidental drunken redundant moderation. I deeply apologize.