4 ms·

I have some answers! * Yes, the JIT is part of the RPython translation toolchain (more on this in a few) and can be used in other interpreters, for example we

I have some answers! * Yes, the JIT is part of the RPython translation toolchain (more on this in a few) and can be used in other interpreters, for example we have Scheme, Javascript, Prolog, and Haskell in varying level of completeness (Prolog being the most complete). * Highly optimized C? Not spectacularly, normal C, not bad, on numerical code we often hover around gcc -O1. * They weren't representative, most of that code was heavily optimized for CPython, which has very different performance characteristics. * RPython is the language the PyPy interpreter is written in, it's not really meant for general purpose code, it's designed mostly for VMs, but it does run at basically C-like speed. * Unladen Swallow was Google's fork of CPython, it's basically dead at this point, retrospective here (http://qinsb.blogspot.com/2011/03/unladen-swallow-retrospective.html http://qinsb.blogspot.com/2011/03/unladen-swallow-retrospect...), Psyco was an extension module for CPython that added a JIT, it's no longer maintained (but still works), it's creator is the lead developer of PyPy. * Cython isn't Python (this could be a meme or something), it does not implement the entire language and thus isn't directly comparable (although we still often compare, because it is a competitor in the space of "making Python-like stuff faster").

wbhart 15y ago
Thanks for the concise and extremely helpful answers. I have some followups: * What is the Jit itself written in? * You mention that for numeric code PyPy hovers around gcc -O1. What are the other classes of code that you see PyPy as having to deal with? And how would it perform compared to normal C on those? * Very interesting comments re the benchmark game. Did anyone ever optimise some of these tasks specifically for PyPy? * Just a clarification re Cython. Yes, I believe it was forked from Pyrex which was mainly for nailing up C code I think. Though since that time my impression is it has become its own language, similar in parts to C/C++ and similar in parts to Python. They appear to have put a fair bit of work into making it fast. It is compiled though (to C), not interpreted. There was some talk about them trying to get it into CPython. But I'm not sure what was meant by that. One final followup: * Do you know if there are any plans to develop a new language built on top of the PyPy VM similar to Python but extended in some way? For example would it be feasible to implement a statically typed language with or without type inference on top of the same technology? By the way, if you google virtual machine you get pages and pages of links to LLVM, JVM, Parrot and Dalvik (go figure) and the occasional reference to a few others. I'm really surprised that the PyPy VM is not better known!
- kingkilr 15y ago
  * The JIT is written in RPython. * Comparing code with C is pretty difficult for all but the easiest 1-1 ports (i.e. numeric stuff), so I don't have good comparison numbers for it. * Yes, I tried to improve the submissions to the benchmark game, this led down a long path which resulted in the benchmark game only having a single implementation for each language (e.g. tracemonkey is no longer on there, only v8) * We don't plan on writing a new language, we kind of like Python, but someone absolutely could. * PyPy doesn't have a VM, we have a toolkit for writing VMs and adding JITs to them. Perhaps these two blog posts will make it more clear: http://morepypy.blogspot.com/2011/04/tutorial-writing-interpreter-with-pypy.html http://morepypy.blogspot.com/2011/04/tutorial-writing-interp... http://morepypy.blogspot.com/2011/04/tutorial-part-2-adding-jit.html http://morepypy.blogspot.com/2011/04/tutorial-part-2-adding-...
  - wbhart 15y ago
    I think I understand now. The PyPy implementation of Python is written using the RPython -> Jit interpreter framework that the PyPy project has. Clever. Am I right in thinking that the drawback of this method is very long compile times for producing the interpreter?
    - kingkilr 15y ago
      Yes, compile times are rather long, about 40 minutes for the full interpreter on a recent, fairly good, laptop. On the other hand you don't need to do a compile all that frequently, because all the code is testable by executing directly atop another Python.
      - StavrosK 15y ago
        So you develop the interpreter by interpreting it on itself before compiling it to itself by itself. Uh...
        cscheid 15y ago
srean 15y ago
Hi Alex, mine might be a minority view/request, but I think RPython is an interesting and useful language in its own right and should be standardized and highlighted. Possibly separated out with a website of its own to emphasize its existence. When I write Python it is rarely the case that I assign values of different types to the same identifier, or add attributes to a class outside of its definition, or monkey patch a module. In other words most of the time I am not really making use of the dynamic properties of the language. In this scenario Python is a language that saves me "finger typing", and I do not needs its dynamic typing as much. I am more than willing, in these scenarios, to trade some of that unused dynamism for better performance. I think there might be others who are similarly inclined. The one thing that I miss in RPython is generators. Is there a particular difficulty because of which it was left out ? I assume so, because all the statically typed variants of Python leave it out as well, but I do not have enough background to know what that difficulty might be. The other is Numpy :) but I believe you guys are working on that. @wbhart A lot of what you ask is answered in some detail in the PyPy blog http://morepypy.blogspot.com/ http://morepypy.blogspot.com/ I wouldnt call PyPy less well known though.
- wbhart 15y ago
  Generators probably need to be efficiently inlined to be fast? Maybe this depends on the capabilities of the VM. I think they can also be implemented with continuations which few languages implement due to being a headscrew. I'm just guessing though. I'd be interested in hearing an authoritative answer. I fully agree re the highlighting and standardizing RPython.
- kingkilr 15y ago
  http://stackoverflow.com/questions/6277174/are-generators-supported-in-rpython/6278734#6278734 http://stackoverflow.com/questions/6277174/are-generators-su... explains why we don't have generators in RPython
  - dochtman 15y ago
    You should put that on the pypy site somewhere.
- 15y ago

wbhart 15y ago

Thanks for the concise and extremely helpful answers. I have some followups: * What is the Jit itself written in? * You mention that for numeric code PyPy hovers around gcc -O1. What are the other classes of code that you see PyPy as having to deal with? And how would it perform compared to normal C on those? * Very interesting comments re the benchmark game. Did anyone ever optimise some of these tasks specifically for PyPy? * Just a clarification re Cython. Yes, I believe it was forked from Pyrex which was mainly for nailing up C code I think. Though since that time my impression is it has become its own language, similar in parts to C/C++ and similar in parts to Python. They appear to have put a fair bit of work into making it fast. It is compiled though (to C), not interpreted. There was some talk about them trying to get it into CPython. But I'm not sure what was meant by that. One final followup: * Do you know if there are any plans to develop a new language built on top of the PyPy VM similar to Python but extended in some way? For example would it be feasible to implement a statically typed language with or without type inference on top of the same technology? By the way, if you google virtual machine you get pages and pages of links to LLVM, JVM, Parrot and Dalvik (go figure) and the occasional reference to a few others. I'm really surprised that the PyPy VM is not better known!

kingkilr 15y ago
* The JIT is written in RPython. * Comparing code with C is pretty difficult for all but the easiest 1-1 ports (i.e. numeric stuff), so I don't have good comparison numbers for it. * Yes, I tried to improve the submissions to the benchmark game, this led down a long path which resulted in the benchmark game only having a single implementation for each language (e.g. tracemonkey is no longer on there, only v8) * We don't plan on writing a new language, we kind of like Python, but someone absolutely could. * PyPy doesn't have a VM, we have a toolkit for writing VMs and adding JITs to them. Perhaps these two blog posts will make it more clear: http://morepypy.blogspot.com/2011/04/tutorial-writing-interpreter-with-pypy.html http://morepypy.blogspot.com/2011/04/tutorial-writing-interp... http://morepypy.blogspot.com/2011/04/tutorial-part-2-adding-jit.html http://morepypy.blogspot.com/2011/04/tutorial-part-2-adding-...
- wbhart 15y ago
  I think I understand now. The PyPy implementation of Python is written using the RPython -> Jit interpreter framework that the PyPy project has. Clever. Am I right in thinking that the drawback of this method is very long compile times for producing the interpreter?
  - kingkilr 15y ago
    Yes, compile times are rather long, about 40 minutes for the full interpreter on a recent, fairly good, laptop. On the other hand you don't need to do a compile all that frequently, because all the code is testable by executing directly atop another Python.
    - StavrosK 15y ago
      So you develop the interpreter by interpreting it on itself before compiling it to itself by itself. Uh...
      - cscheid 15y ago

srean 15y ago

Hi Alex, mine might be a minority view/request, but I think RPython is an interesting and useful language in its own right and should be standardized and highlighted. Possibly separated out with a website of its own to emphasize its existence. When I write Python it is rarely the case that I assign values of different types to the same identifier, or add attributes to a class outside of its definition, or monkey patch a module. In other words most of the time I am not really making use of the dynamic properties of the language. In this scenario Python is a language that saves me "finger typing", and I do not needs its dynamic typing as much. I am more than willing, in these scenarios, to trade some of that unused dynamism for better performance. I think there might be others who are similarly inclined. The one thing that I miss in RPython is generators. Is there a particular difficulty because of which it was left out ? I assume so, because all the statically typed variants of Python leave it out as well, but I do not have enough background to know what that difficulty might be. The other is Numpy :) but I believe you guys are working on that. @wbhart A lot of what you ask is answered in some detail in the PyPy blog http://morepypy.blogspot.com/ http://morepypy.blogspot.com/ I wouldnt call PyPy less well known though.

wbhart 15y ago
Generators probably need to be efficiently inlined to be fast? Maybe this depends on the capabilities of the VM. I think they can also be implemented with continuations which few languages implement due to being a headscrew. I'm just guessing though. I'd be interested in hearing an authoritative answer. I fully agree re the highlighting and standardizing RPython.
kingkilr 15y ago
http://stackoverflow.com/questions/6277174/are-generators-supported-in-rpython/6278734#6278734 http://stackoverflow.com/questions/6277174/are-generators-su... explains why we don't have generators in RPython
- dochtman 15y ago
  You should put that on the pypy site somewhere.
15y ago