pypy-0.7.0: first PyPy-generated Python Implementations ============================================================== What was once just an idea between a few people discussing on some nested mailing list thread and in a pub became reality ... the PyPy development team is happy to announce its first public release of a fully translatable self contained Python implementation. The 0.7 release showcases the results of our efforts in the last few months since the 0.6 preview release which have been partially funded by the European Union: - whole program type inference on our Python Interpreter implementation with full translation to two different machine-level targets: C and LLVM - a translation choice of using a refcounting or Boehm garbage collectors - the ability to translate with or without thread support - very complete language-level compliancy with CPython 2.4.1 What is PyPy (about)? ------------------------------------------------ PyPy is a MIT-licensed research-oriented reimplementation of Python written in Python itself, flexible and easy to experiment with. It translates itself to lower level languages. Our goals are to target a large variety of platforms, small and large, by providing a compilation toolsuite that can produce custom Python versions. Platform, Memory and Threading models are to become aspects of the translation process - as opposed to encoding low level details into a language implementation itself. Eventually, dynamic optimization techniques - implemented as another translation aspect - should become robust against language changes. Note that PyPy is mainly a research and development project and does not by itself focus on getting a production-ready Python implementation although we do hope and expect it to become a viable contender in that area sometime next year. Where to start? ----------------------------- Getting started: http://codespeak.net/pypy/dist/pypy/doc/getting-started.html PyPy Documentation: http://codespeak.net/pypy/dist/pypy/doc/ PyPy Homepage: http://codespeak.net/pypy/ The interpreter and object model implementations shipped with the 0.7 version can run on their own and implement the core language features of Python as of CPython 2.4. However, we still do not recommend using PyPy for anything else than for education, playing or research purposes. Ongoing work and near term goals --------------------------------- PyPy has been developed during approximately 15 coding sprints across Europe and the US. It continues to be a very dynamically and incrementally evolving project with many one-week meetings to follow. You are invited to consider coming to the next such meeting in Paris mid October 2005 where we intend to plan and head for an even more intense phase of the project involving building a JIT-Compiler and enabling unique features not found in other Python language implementations. PyPy has been a community effort from the start and it would not have got that far without the coding and feedback support from numerous people. Please feel free to give feedback and raise questions. contact points: http://codespeak.net/pypy/dist/pypy/doc/contact.html contributor list: http://codespeak.net/pypy/dist/pypy/doc/contributor.html have fun, the pypy team, of which here is a partial snapshot of mainly involved persons: Armin Rigo, Samuele Pedroni, Holger Krekel, Christian Tismer, Carl Friedrich Bolz, Michael Hudson, Eric van Riet Paap, Richard Emslie, Anders Chrigstroem, Anders Lehmann, Ludovic Aubry, Adrien Di Mascio, Niklaus Haldimann, Jacob Hallen, Bea During, Laura Creighton, and many contributors ... PyPy development and activities happen as an open source project and with the support of a consortium partially funded by a two year European Union IST research grant. Here is a list of the full partners of that consortium: Heinrich-Heine University (Germany), AB Strakt (Sweden) merlinux GmbH (Germany), tismerysoft GmbH(Germany) Logilab Paris (France), DFKI GmbH (Germany) ChangeMaker (Sweden), Impara (Germany)
I tried translating pypy on my AMD64 laptop and it translated fine, compilation did finally run the machine out of ram. The machine was somewhat usable during the transation as the python process was only using ~700 of 784MB of RAM (everything constantly swapping of course). It got a bit more rocky during the C code generation when the usage slowly went up by another 50MB. But I quit trying to code with it in the background and let it continue. After a while I checked and it had started to compile this continued, very slowly, for long while longer at one point the cc1 process was using over 800MB. The lesson here is that it isn't really posible to translate it on a 64-bit machine with a normal amount of RAM, yet. Also I got a bunch of warnings from the C compiler: "warning: cast to pointer from integer of different size". This sounds to my like the code assumes that the int is the same size as the pointer and it isn't on my machine. And I suspect the result would not have been runable because of it. The end of the story is that I was running out of RAM and swap and I tried to add a swap file and the kernel killed the cc1 process. BTW, The machine has in excess of 900MB of swap and my gnome session only uses a couple hundred MB, so the compilation must have use an /huge/ amount of memory to overflow the well over 1GB of available VM. After the cc1 process was killed I was able to switch back to the X vt and the graph viewer window had poped up and seemed to work. I figure you know or could have guessed this would happen, but I thought I'd send a report. Hope it is useful. -Arthur PS: BTW, I'm willing to try it again if it would help. This time I will kill everything unnessisary and use 2-3GB of swap ;-)
Hi Arthur, On Sun, Aug 28, 2005 at 05:15:58PM -0500, Arthur Peters wrote:
I tried translating pypy on my AMD64 laptop and it translated fine, compilation did finally run the machine out of ram.
As it got as far as generating the .c source, you can try aborting the translation at this point and compiling the testing_1.c file manually with no translate_pypy.py left in the background. This also has the advantage that you can control which options you pass to gcc, so you can disable advanced optimizations. E.g. (fix the paths, of course): $ cd /tmp/usession-NN/testing_1/ $ gcc -c testing_1.c -o testing_1.o -I/usr/include/python2.4 \ -I/path/to/pypy/translator/c $ gcc -lpthread -lm testing_1.o -o pypy-c Armin
participants (3)
-
Armin Rigo
-
Arthur Peters
-
hpk@trillke.net