Hello all, "Rumors have it that the secret goal is being faster-than-C which is nonsense, isn't it?" My thinking about this has changed since then as the result of reading the following two excellent HP tech reports:
http://www.hpl.hp.com/techreports/1999/HPL-1999-77.pdf http://www.hpl.hp.com/techreports/1999/HPL-1999-78.pdf These papers should convince any skeptic that PyPy is feasible. The first report is a summary; the second provides more details. I won't discuss them in detail; they are clear enough. Here is the key sentence from the abstract of the first paper: "Contrary to intuition, we demonstrate that it is possible to use a piece of software to improve the performance of a native, statically optimized program binary, _while it is executing_." (emphasis in original). The phrase "contrary to intuition" is apt". One would have thought that interpreting opcodes in software and maintaining a cache (also in software) would be way too expensive. Apparently not. It is this surprise that makes these papers so important. If Dynamo can optimize the binary output of compilers at run time, totally in software with no assist whatever from the compilers or any other part of the OS, then a similar approach certainly can certainly optimize either Python's C interpreter main loop or Python's byte codes directly. Whether the specific approach discussed in these papers would be of value is something for PyPy's designers to decide. The more people are convinced that PyPy is feasible, the more people will be inspired to contribute to it. Edward P.S. I regretted being able to see you all at PyCon this March. I would have been most interested in the PyPy papers. I wonder if the various PyPy authors would mind sending me notes of their presentation? I did pay for the conference; I just was not able to attend. P.P.S. Iirc I found these reports after reading about "code morphing" and doing a bit of googling. I don't think I found about them from here :-) P.P.P.S. In the next several weeks I shall add the so-called @file-thin feature to Leo. This will allow Leo to be used in highly cooperative environments managed by cvs or subversion or whatever. In the short term, this is likely to be the extent of my contribution to the PyPy project. P.P.P.S. Think what might happen if hardware used a similar caching scheme... EKR -------------------------------------------------------------------- Edward K. Ream email: [EMAIL PROTECTED] Leo: Literate Editor with Outlines Leo: http://webpages.charter.net/edreamleo/front.html -------------------------------------------------------------------- _______________________________________________ [EMAIL PROTECTED] http://codespeak.net/mailman/listinfo/pypy-dev
