
PyPy: the other new compiler project - corbet
http://lwn.net/SubscriberLink/388160/52ddb2785b47e70b/
======
ableal
Off-topic: I was intrigued by the 'ATS' in the shootout (don't remember it
being there a couple of years ago).

I had followed the link posted by rodion_89 (2008 blog), into
<http://shootout.alioth.debian.org/#acceptable> (nice opening and closing) and
[http://shootout.alioth.debian.org/u64/performance.php?test=b...](http://shootout.alioth.debian.org/u64/performance.php?test=binarytrees)
\- where 'ATS' sits at #3 (behind C and C++, edging out Java6).

The code (e.g.
[http://shootout.alioth.debian.org/u64/program.php?test=binar...](http://shootout.alioth.debian.org/u64/program.php?test=binarytrees&lang=ats&id=3)
) does not look too ugly, but apparently it may be twice as verbose as C++ (
<http://shootout.alioth.debian.org/u32/ats.php> ).

So, on to <http://www.ats-lang.org/> :

 _ATS is a programming language with a highly expressive type system rooted in
the framework Applied Type System. In particular, both dependent types and
linear types are available in ATS. The current implementation of ATS
(ATS/Anairiats) is written in ATS itself. It can be as efficient as C/C++ (see
The Computer Language Benchmarks Game for concrete evidence) and supports a
variety of programming paradigms that include:

\- Functional programming. [...]

\- Imperative programming. [...]

\- Concurrent programming. [...]

\- Modular programming. [...]_

------
metamemetics
PyPy while great news for Python, is still a snail compared to another high-
level language JIT, LuaJIT:

[http://shootout.alioth.debian.org/u32/benchmark.php?test=all...](http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=luajit&lang2=pypy)

edit: bit of background: Lua is a minimalist dynamic language. It can be used
anywhere in your web development request stack since mod_lua was included in
Apache 2.3.

~~~
Raphael_Amiard
And it also has nothing to do with it from an architectural point of view.
LuaJIT's code is not generally reusable. It's highly optimized, often platform
specific C and assembler code. PyPy is an experimental (in the good way) and
successful attempt at using a subset of python to make a faster python
interpreter than the native C interpreter, while in the process creating a
platform to create other optimized dynamic languages interpreters. It's code
is highly general and readable, especially compared to something as specific
and low level than LuaJIT. In the process, the devs have created a new
language, rpython, that is as fast as C while being much more expressive.

Lua is also a much simpler language than python, and therefore a much better
target to fine tuned optimizations.

You could almost say that LuaJIT is a pragmatic project, and pypy an
idealistic one. And they're both succeeding. But they don't have the same
goals at all.Please dont compare them without giving a bit of background. It's
very misleading.

~~~
monopede
Do you have any references for your "as fast as C" part? That seems like a
very dubious claim.

If your ultimate goal is performance, I believe PyPy is fundamentally flawed
because it already introduces two levels of indirection that cannot easily be
removed. Of course their goal seems to be to simply be faster than the python
interpreter and remain maintainable at the same time. They appear to be
succeeding at that and I congratulate them on that.

LuaJIT takes the right approach w.r.t. performance. The interpreter for LuaJIT
2 is well-optimised and not actually that hard to understand. This goes
together with a well-chosen set of interpreter instruction set and
intermediate representation. All these layers require careful design, and Mike
Pall didn't come up with this over night.

~~~
stephenjudkins
Here's how RPython is "faster than C":

1\. PyPy's Python interpreter is written in RPython, a subset of Python.

2\. CPython is an interpreter written in C.

3\. When compiled into a JIT, PyPy's Python interpreter is now generally
faster than CPython, sometimes by a wide margin.

4\. Code written in RPython is faster than code written for a nearly identical
purpose in C. The C code in question has been the target of aggressive
optimizations for years while the RPython code is relatively immature.

Now, for many applications I'm sure C remains faster than RPython. But for the
application RPython is designed for--writing an interpreter for a dynamic
language--I think it is safe to say that RPython appears faster than C.

The fact that the PyPy's interpreter is cleaner, safer, and more maintainable
than equivalent C code is also a huge win. Again, the point of the original
post is that RPython could become an simple implementation language to create
fast interpreters for dynamic languages. It could also become a target
language for other compilers.

Anyways, as others have pointed out, Lua is a considerably simpler language
than Python. LuaJIT is a really remarkable piece of engineering, especially
since it was written by one guy, but it's really a completely different
project than PyPy. Its aim is to make Lua--and only Lua--extremely fast. If
PyPy's Python implementation gets no faster (which I think is unlikely) the
potential ability to easily create new dynamic languages that are similarly
speedy is itself an amazing achievement.

~~~
jemfinch
> 4\. Code written in RPython is faster than code written for a nearly
> identical purpose in C.

This is where your argument falls down. Selection sort and heap sort are both
written for the identical purpose, but due to their different designs and
different complexities, a heap sort written in _ordinary_ Python would
outperform a selection sort written in C for a great many inputs. This does
not prove that Python is faster than C, it simply proves that two programs,
even written for the identical purpose, can achieve that purpose in vastly
different ways, and those differences can greatly impact the performance of
those programs.

~~~
jemfinch
A downmod but no counterargument? Sad.

