Mailman 3 December 2004 - pypy-dev

bug in http://codespeak.net/moin/pypy/moin.cgi/FrontPage?action=show
by Laura Creighton Oct. 10, 2005

Oct. 10, 2005

If you click on the 'documentation' link you get a traceback! ooops. I will look at this later unless somebody beats me to it. Laura

5 4

Re: [Edu-sig] Learn to Program in Ten Years
by Laura Creighton Dec. 30, 2004

Dec. 30, 2004

First attempt to explain to Dethe. Comments? Improvements? I think that explaining clearly to edu-sig is very important, but I am far from the world's best explainer. I'd like a better job than what I did here, but am unsure what to change. I think it is too long, for one thing, but then maybe I am biased. Laura -------- Happy New Year, Dethe! Thank you for your interest. You write: >PyPy uses a similar approach to Pyrex, called Psyco, which compiles >directly to 80x86 machine code (Pyrex compiles to cross-platform C >code). This allows PyPy to attempt to be faster than C-Python by >creating compiler optimizations. Not sure what the PyPy story is for >non-x86 platforms. There is also a project to recreate Python on top >of Smalltalk, by L. Peter Deutch, which he expects to be faster than >C-Python (and if anyone can do it, he could). > >Nice to see y'all again. Happy New Year (or Gnu Year?). > >--Dethe > I'd like to clarify a few misunderstandings I think you have. Psyco is not a technique, but rather a specialising compiler available as a Python extension module. It compiles directly to 386 machine code. PyPy, on the other hand, currently emits C code. Our previous version emitted Pyrex code. Some people in Korea are making a version that emits Lisp code. PyPy doesn't use Psyco, though many ideas are common to both. What's more there is nothing magic about machine code that makes it automatically fast -- an inefficiently-coded algorithm in assembler is still a turtle. The win in using PyPy is not about 'saving the time it takes to have a conversation with your C compiler', but instead about making such conversations more productive and useful. The more information you can tell your C compiler about your data, the better code it is prepared to generate. This is the tradeoff between flexibility and speed. When your Python system sees x = a + b it has no clue as to what types a and b are. They could be anything. This 'being ready to handle everything' has a large performance penalty. The runtime system has to do be prepared to do a _lot_, so it has to be fairly intelligent. All this intelligence is in the form of code instructions, and there are a lot of them that the runtime system has to execute, every time it wants to do anything at all. On the other hand, at code _reading_ time, the Python interpreter is purposefully stupid-but-straightforward. It doesn't have much to do, and so can be relatively quick in not doing it. A statically-typed compiled langauge works in precisely the other way. When the runtime system of a statically typed language sees x = a + b, it already knows all about x, a and b and their types. All the hard work was done in the compiling phase. There is very little left to worry about -- you might get an overflow exception or something -- but as an oversimplification, all the runtime system of a statically typed system has to know how to do is how to load and run. That's fast. So, one way you could speed up Python is to add type declarations, thus simplifying the life of the runtime system. This proposed solution more than a little drastic for those of us who like duck typing, signature based polymorphism, and the particular way coding in Python makes you think and feel. The PyPy alternative is to make the interpreter even smarter, and a whole lot better at remembering what it is doing. For instance, when it sees x = a + b instead of just adding this particular int to this particular int, it could generate some general purpose code for adding ints to ints. This code could be thus used for all ints that you wish to add this way. So while the first time is slow, the _next_ time will be a lot faster. And that is where the performance speedup happens -- in code where the same lines get run again, and again, and again. If all you have is a mainline where each line of code gets executed once, then we won't help you at all. Psyco is about as far as you can get with this approach and be left with a module you can import and use with regular python 2.2 or better. See: http://psyco.sourceforge.net/ PyPy is what you get when you pitch the old interpreter and write your own. See: http://codespeak.net/pypy/ And we should probably move further disussion to pypy-dev, here: http://codespeak.net/mailman/listinfo/pypy-dev Thanks for your interest, and thanks for writing, Laura Creighton (for PyPy)

2 1

Re: [Edu-sig] Learn to Program in Ten Years (Laura Creighton)
by Jason Mobarak Dec. 30, 2004

Dec. 30, 2004

> Message: 1 > Date: Thu, 30 Dec 2004 11:24:20 +0100 > From: Laura Creighton <lac(a)strakt.com> > Subject: [pypy-dev] Re: [Edu-sig] Learn to Program in Ten Years > To: pypy-dev(a)codespeak.net > Message-ID: <200412301024.iBUAOKfQ005915(a)ratthing-b246.strakt.com> > Content-Type: text/plain; charset=iso-8859-1 > > OUr message is getting out garbled: > > http://mail.python.org/pipermail/edu-sig/2004-December/004331.html > > Wonder what to reply ... > > Shall I take this one, or does somebody else want to? > > Laura > Please post the reply, if you do indeed post a correction. Thanks ,,Jason

1 0

Re: [Edu-sig] Learn to Program in Ten Years
by Laura Creighton Dec. 30, 2004

Dec. 30, 2004

OUr message is getting out garbled: http://mail.python.org/pipermail/edu-sig/2004-December/004331.html Wonder what to reply ... Shall I take this one, or does somebody else want to? Laura

2 1

Monte Carlo simulation in Python
by Laura Creighton Dec. 27, 2004

Dec. 27, 2004

http://peter.mapledesign.co.uk/weblog/archives/python_is_slow.html Maybe we want to use this as a benchmark as a test of 'I didn't know how to write optimised code but PyPy did it anyway?' More or less for archival purposes. Sometimes when you need code like this, you cannot seem to find any ... Laura

2 1

PyCon?
by Armin Rigo Dec. 26, 2004

Dec. 26, 2004

Hi all, I guess we should submit a PyCon talk about PyPy, right? "PyPy, status report", or something more elaborate? I would prefer not to mix "how to get EU money" with the technical presentation this time... Armin

2 1

Re: [pypy-dev] PyCon?
by Laura Creighton Dec. 26, 2004

Dec. 26, 2004

In a message of Sun, 26 Dec 2004 08:59:05 GMT, Armin Rigo writes: >Hi all, > >I guess we should submit a PyCon talk about PyPy, right? > >"PyPy, status report", or something more elaborate? > >I would prefer not to mix "how to get EU money" with the technical >presentation this time... > > >Armin >_______________________________________________ >pypy-dev(a)codespeak.net >http://codespeak.net/mailman/listinfo/pypy-dev I actually think they want a talk on 'what is static type inference' and how we do it. Laura x

1 0

Upcoming PyPy sprint
by Armin Rigo Dec. 25, 2004

Dec. 25, 2004

Hi Python people, The next sprint for PyPy, the Python-in-Python interpreter, will take place in Leysin, in the lower mountains of Switzerland, 22nd - 29th January 2005 (travel days: 22nd and 29-30th) http://codespeak.net/moin/pypy/moin.cgi/LeysinSprint The technical goals will be two-fold: we want to continue the hard work started at the previous Vilnius sprint (a first generated C version of our interpreter); but the upcoming sprint will also be a "learning PyPy" sprint, covering all aspects of PyPy that are easier to start with. Some examples are described below. For more information about PyPy, see http://codespeak.net/pypy/index.cgi?doc . The "learning PyPy" focus comes from the fact that it will be our first sprint as a European Union sponsored group, and not all members of this EU/PyPy project are already familiar with PyPy. This is a good occasion for newcomers that want to look at PyPy more closely too, in a "fun and somewhat mind-altering" sprint event. Note that as part of our funding we want to be able to support some of the travel and lodging costs for a number of outside people as well, but although the corresponding money is in the budgets, not all administrative issues have been solved yet. We don't know yet if we will be able to do so for the January sprint. However, if you would like to come to the sprint but can't afford travel and accomodation costs then please contact us. Even if the administrative issues have not been sorted out, we may be able to help with private money. Just contact us or me personally for this sprint. About Leysin ------------ The place where the sprint will take place is located in the pre-Alps of the french-speaking (west) region of Switzerland. Leysin is a village at an altitude of 1200 to 1400m. It is a skiing station, and also the place where I (Armin) lived for 20 years. There are 2000 people in summer and 10000 in winter :-) but the sprint will be just before the most crowded periods of February. Of course one full day will be dedicated to winter sports! Both the sprint venue and the logding will be in a very spacious pair of chalets built specifically for bed&breakfast: http://www.ermina.ch/. The place has a baseline ADSL Internet connexion (600Kb); we need to arrange between ourselves to bring a wireless hub. You can of course arrange your own lodging anywhere (you cannot be more than a 15 minutes walk away from the sprint venue), but I definitely recommend to lodge there too -- you won't find better sights anywhere else (though you probably won't get much worse ones easily, either :-) Subscription ------------ Please subscribe at http://codespeak.net/moin/pypy/moin.cgi/LeysinSprintAttendants and mention if you would like to participate in the group reservation, and which size of room you would prefer (2 to 6 beds available). If you wish, you can extend your stay for some days after the 29th of January -- please mention it if you want to book with the group (but you cannot arrive there earier than the 22nd: fully booked). If you have any question don't hesitate to contact pypy-sprint(a)codespeak.net or one of us personally. Learning PyPy ------------- Here are some goals that are quite reachable without in-depth prior knowledge of PyPy: * systematic testing: the interpreter and type implementations work generally well, but there are quite some areas that need refactoring and refinement. A good approach is to run as many of CPython's tests as possible and fix stuff accordingly. This is a good way to learn random parts of PyPy until you know them all! * extension modules and extension types: some can be just rewritten as a plain Python equivalent, but others need to be more integrated into PyPy's internals. * the bytecode compiler: we don't have any compiler integrated with PyPy so far, but there exists a complete set of Python code out there (tokenizer, parser, st->ast, ast->bytecode) that could be used. We could also discuss ideas like syntax extensions generating new bytecodes, etc. * tracing and other wrappers: e.g. how to write a fully debugging Object Space that records the history of all changes to objects, etc. * more bits and pieces: small things missing from our interpreter to be fully compliant. Tracing/profiling hooks come to mind; more small things are listed in http://codespeak.net/svn/pypy/trunk/src/pypy/TODO . In addition to the above examples, there are a number of more involved tasks that nevertheless don't require a complete grasp of PyPy -- whose parts are relatively independent from each other. The "hard" work currently going on in PyPy is on the translation part, which is needed to make PyPy run faster and/or in other environments. This work is however mostly independent. For people that prefer to focus on cross-language stuff rather than Python internals we can discuss about tasks like writing the basics of an interpreter for another language -- for example, it would be great to have a decent error-checking Javascript interpreter, but we can discuss any other language, Python-like or not. In parallel, there is always pending work to allow the code generator to target other languages and platforms (currently there is C, Lisp, Pyrex and Java) or generate code differently (Stackless-style, Psyco-style). A bientot, Armin Rigo

1 0

amusement
by Michael Hudson Dec. 16, 2004

Dec. 16, 2004

Hacking annrpython.py to just shrug and continue when processing a block fails results (fairly quickly! a few minutes on the ibook) in C which compiles and imports but does this when run: >>> entry_point_1.entry_point() Traceback (most recent call last): File "<stdin>", line 1, in ? File "entry_point_1.c", line 20236, in gfunc_call_args() OP_GETATTR(v12779, gstr_run, v12834, err0_17) AttributeError: 'SpecialMmFrame' object has no attribute 'run' I think we need to sort *-args out fairly soon. Cheers, mwh -- <glyph> "Fetch me my internet pants." -- from Twisted.Quotes

2 1

codespeak down?
by Florian Schulze Dec. 15, 2004

Dec. 15, 2004

Hi! I don't know whether this mail comes through or not, but it seems like codespeak.net is down. Regards, Florian Schulze

2 1