Mailman 3 January 2003 - pypy-dev

[Fwd: Re: [pypy-dev] Re: psyco in Python was: Minimal Python project]
by Boyd Roberts 20 Jan '03

20 Jan '03

Hey, can we get a Reply-to: on this list? -------- Original Message -------- Subject: Re: [pypy-dev] Re: psyco in Python was: Minimal Python project Date: Mon, 20 Jan 2003 11:13:12 +0100 From: Boyd Roberts <boyd(a)strakt.com> To: Christian Tismer <tismer(a)tismer.com> References: <Pine.LNX.4.44.0301171553220.25684-100000(a)starship.python.net> <3E2855C7.5010107(a)gmx.de> <3E289AB8.105(a)tismer.com> Christian Tismer wrote: > Thomas Fanslau wrote: > > ... > >> And don't forget the obvious replacement of a multiply by some >> shifts, so multiply by 5 can be replaced by a copy, a right shift 2 >> places and a add instead of a costly multiply ... > > > Ok, my 2 Eurocent: > > Also don't forget that this is not always true. Yes, on the VAX a _floating point_ multiply was faster than a shift.

2 1

question about core implementation language
by Stephan Diehl 20 Jan '03

20 Jan '03

Hi all, while reading all these long mails about this exciting project, one basic question came to my mind: why has the core implementation to be in C? Years ago I did a little programming in Objective C and I just loved this language (I'm taking about gcc objc without the framework by NeXT/Apple). Here are some good things about Objective C: 1. Legal C code is already legal Objective C code 2. Objective C has a runtime engine build in. 3. objects classes don't need to be known at compile time (just their interfaces) Having said that, I could imagine that it's much easier to model python objects in Objective C than in C, thus making the needed core more compact and easier to maintain. Stephan

5 5

Re: [pypy-dev] question about core implementation language
by logistix 20 Jan '03

20 Jan '03

"Edward K. Ream" <edream(a)tds.net> wrote: > > > I have started some prototyping in Python, and I now > > remember some words of Guido, that Python isn't specially > > well suited for such a task. I admit, there is some > > truth in it. > > I don't understand Guido's comment. I personally think Python is absolutely > superb for any prototyping endeavor. > > Perhaps I am being dense, but the fact that Python doesn't have feature x of > language y seems totally a non-issue. You want a switch statement? Write a > psyco_switch function (in Python, of course). Ditto for anything else your > heart desires. Eventually _everything_ that generates code is going to > become assembly code, but that is no problem at all for any compiler. > > Perhaps I am confusing levels of discussion or implementation. However, the > way I see it, the most important thing is to do experimentation with > algorithms. To do that, the essential thing is to compare various ways of > doing things, at as high a level as possible. In other words, a > psyco_switch routine provides a good enough model for the task at hand. > Ditto for any other construct you want. > > Actually, for experimentation (perhaps leading to inspiration) I wouldn't > necessarily confine myself to any particular level of implementation or > design or whatever. I would simply blast away using whatever language tools > appear to be most useful. Armin has talked about doing high-level work with > discovering list optimizations, for example. I don't understand what the > lack of a Python switch statement has to do with such matters. > > In short, I would hardly bother at all with questions of the level at which > Python is modeling some implementation. I would use whatever works in > Python and worry about mapping that back to a final implementation only > after it is clear that Python in Python will be a big win. At that time we > will have lots more data, energy and incentive to do the needed grunt work. > Until then, I wouldn't let implementation problems get in the way of > invention. > > Just my $0.02. > > Edward > > > > _______________________________________________ > pypy-dev mailing list > pypy-dev(a)codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev > I think the point is that Python as a language provides absolutely no access to the machine internals. You can't examine memory contents, registers, I/O bus or call code directly. As part of the bootstrap process the following four functions should probably be added to the interperter (either as builtin functions or a module): GetMemoryFromOS() ReturnMemouryToOS() Peek() Poke() ANd probably: get/putRegister() callCode() Other than that, everything could (eventually) be written in Python. --------------------------------------- Get your free e-mail address @zworg.com

2 1

From PyPy to Psyco
by Armin Rigo 20 Jan '03

20 Jan '03

Hello everybody, Ok, sorry about not posting earlier on this list. Sorry too for the long e-mail; I wanted to reply to individual e-mails, but it seems that the subjects always overlap. So I'm just dropping my thoughts here. Bootstrapping issues where quite widely discussed. There are several valid approaches in my opinion. I would say that we should currently stick to "Python in Python"'s first goal: to have a Python interpreter up and running, written entierely in Python. (1) write a Python interpreter in Python, keeping (2) in mind, using any recent version of CPython to test it. Include at least the bytecode interpreter and redefinition of the basic data structures (tuple, lists, integers, frames...) as classes. Optionally add a tokenizer-parser-compiler to generate bytecode from source (for the first tests, using the underlying compile() function is fine). Only when this is done can we invent nice ways to do interesting things on this interpreter. The approach I prefer is: (2) have a tool that can perform a static analysis of the core of (1). To make this possible this core has to be written using some restricted coding style, using simple constructs (and not full of Python tricks and optimizations; something like Rocco describes). (3) this tool compiles the core (via C code) into several different things: (3a) the classical approach (like e.g. in smalltalk) is to emit C code that is very similar to the original Python code, much like Pyrex does. We obtain a stand-alone minimal interpreter. By interpreting the rest of (1), we get an already nice result: a stand-alone complete Python interpreter with a small amount of C -- and, more interestingly, almost all this C code was itself automatically generated from Python code. To bootstrap the tokenizer-parser-compiler written in unrestricted Python, simply provide a bytecode-precompiled version of it along with the C file. Keep in mind that both the C files and the precompiled .pyc files are intermediate files, automatically regenerated as often as needed, and only distributed for bootstrapping purposes if we want to be independent from CPython. (3b) among other things that can be generated from (2) are a bytecode checker, which CPython currently lacks and Guido sometimes thinks would be a nice addition to prevent 'new.code()' from crashing the interpreter. (I already experimented with this, it can work.) (Note that we are not forced a priori to choose the same set of bytecodes as CPython, but doing so is probably a good idea at this stage.) (3c) Psyco stuff: given a few extra hints, the code generated from (2) can be Psyco itself. I mean, I am not thinking about introducing the current C-based Psyco into the play to execute (1) faster. This would at best give the same performance as CPython --- and I seriously doubt it can be as fast as that, given that Psyco's limited back-end cannot compete with serious C compilers. Instead, we can generate C code which constitutes a new Psyco for the language that (1) is an interpreter for. In short, we would have translated our interpreter into a specializing compiler. What is nice, of course, is that the same would also work if (1) were an interpreter for a different language. This is not magic; specialization is known to be a tool that can translate any interpreter into a compiler. What's new here is the dynamic nature of the choice of what is compile-time and what is run-time. For (3b) and (3c) I am thinking about emitting C code, but this is not a requirement: it would be possible to emit Python code too, for example to build a Python-based bytecode checker. But if we did the static type analysis in (2), we might just as well emit C code to keep the discovered static type declarations. Related points: * Platform-specific bootstrapping tools. Looks like I favour the idea that everything is managed by the tool in (3a) (which is itself in Python, of course). This tool could emit platform-specific C code when possible, or (for redistribution) a generic low-quality platform-independent version that would suffice to run (3a) again. As the C code is not really meant to be compiled more than once we can avoid 'make' tools --- for all I care it could even be a single large C file, as it is not manually managed anyway. * Representation of data structures. Use Python classes, e.g. integers are implemented using a "class PyIntObject" with an ob_ival attribute (or property). These classes are straightforwardly translated into a C struct by (3a). The structure can be made compatible with CPython's PyIntObject, or alternatively can be built for a GC-based interpreter with no reference counting, if we wanted to try such a thing. * Foreign Function Interface (a.k.a. calling external C functions). Two approches here. I believe that in a first stage it is sufficient to emit the real calls in our C code, by translating some static Python declaration with (3a). All such callable functions must be pre-declared to get compiled into the stand-alone core interpreter. This doesn't give get dynamic call features like those offered by some existing CPython C extensions. But a form of dynamic calls is necessary for Psyco --- it must at the very least be able to emit machine code that calls arbitrary C functions. So I'm trying to push this whole issue into the context of emitting machine code by Psyco: when this works it should not be a problem to expose some of the techniques in a built-in extension module to let end users call arbitrary C functions. Before that I don't think there is a need for enhanced 'struct', 'calldll' and 'ctypes' modules. * Psyco as a compiler. If no C compiler is available, Psyco can be used to emit statically-known code; I guess we can bootstrap a whole Python interpreter without even leaving CPython, just by having Psyco's back-end do the (3a) or even (3c). That's nice, althought I cannot think of a real use for this :-) * CPython. The above plan only uses CPython for its ability to run Python programs and for the hopefully shrinking number of features that are not re-implemented in (1). The CPython source code is used for inspiration, not compilation. * Python Virtual Machine. In the above plan there is no need for a small Python VM in C for bootstrapping. * Assembly Virtual Machine. Something else that Christian mentionned was a low-level VM that would provide a cool target for emitted machine code. For all static stuff I see C as a nicer low-level target, but for Psyco it might be interesting to have a general platform-independant target. Another cool Psyco thing would be to never actually emit code in a first phase, but only gather statistics that would later let a specialized C version of parts of the program be written and compiled statically. There are so many cool things to experiment, I can't wait to have (1) and (2) ready --- but I guess it's the same for all of us :-) A bientot, Armin.

2 2

Re: [pypy-dev] Re: psyco in Python was: Minimal Python project
by Edward K. Ream 19 Jan '03

19 Jan '03

Hi Michael, I'm going to copy this to pypy-dev so that other people can see this discussion. > > > > I just don't see how to implement psyco in Python in a production > > > > package without using the C interpreter as a bootstrap! And yes, I > > > > suspect that a C language version of psyco will be faster than psyco > > > > in Python. > > > Even after you've run psyco over itself? > > > > Yes, maybe even then. C compilers should do better _on the same > > algorithm_ on hand-written code than can any GIT. > Weeeeellll, this is the thing that gets me jumping-up-and-down-excited > about things like psyco: pysco has MORE information than the C compiler to > work with: while the C compiler only knows the algorithm to run, psyco > knows both the algorithm *and the data it is to run on*. Obviously, this > approach only wins if what you do next resembles what you did last, but I > think CPU caches have proved there is some mileage in that idea :) I don't think CPU caches have much bearing on this discussion. Caches speed up frequently used values. The problems here are not the same. The more I study psyco, the more I am convinced that there is _no way_ that psyco will ever produce better code than a C compiler. In brief, my reasons are as follows: 1. psyco has, in fact, no better information than does a C compiler. Remember that the "values" that psyco specializes upon are in fact _interpreter_ vars, so knowing those values is equivalent to knowing the types of operands. This does indeed allow psyco to emit machine code that is better than the equivalent C interp generic code. In fact, though, most of what psyco is doing is quite routine: replacing bytecode by assembly language. This will speed up the code a _lot_, but it is doing just like a C compiler does. 2. I have looked again at the code generators of the optimizing C compiler I wrote about 10 years ago. I can find no instance where knowing the value of an operand, rather than just its type, would produce better code. Yes, my compiler did constant folding (which eliminates code rather than improves it), but I do not believe doing constant folding at runtime is going to improve matters much, and is in fact very likely to slow down the running times of typical programs, for reasons given below. 3. It's easy to get seduced by the "psyco has more knowledge" mantra. In fact, one mustn't lose track of the obstacles psyco faces in outperforming C compilers. First, and very important, everything that psyco does must be done at run time. This means that even very effective optimizations like peephole optimizations become dubious for psyco. Second, and also very important, is that fact that psyco (or rather the code that psyco produces) must determine whether the code that psyco has already produced is suitable for the task at hand. The "Structure of Psyco" paper says this: "Dispatching is the set of techniques used to store a trace of the compiled code buffers and _find if one already matches the current compiler state_" (emphasis mine) In other words, it's not enough to specialize code! Psyco must determine whether the types used to compile a function match the types presently given to psyco. This searching is done in the "compatible" routine, and no matter how it is done is _pure overhead_ compared to the code generated by a C compiler. As I see it, both these issues are "gotchas". Neither can be eliminated completely, and each introduces overhead that will make the code emitted by psyco clearly inferior to the code produced by any decent C compiler. In particular, the more psyco specializes on runtime values of operands the bigger the code bloat and the more severe the problem of finding out what already-compiled code to use. 4. I have seen _nothing_ in psyco's algorithms or the code emitted by psyco that leads me to believe that psyco is "doing enough work" to outperform a C compiler. When I was a mathematics graduate student 30 years ago one of my professors made the remark that a mathematician need to develop a feel for the level of work required to do a new proof. Deep insights are not going to come from elementary methods, and there is no use in using deep methods to prove elementary results. I believe the same kind of analysis can (and should!) be done here. Yes, psyco is clever. In some ways it is _very_ clever, especially the idea of modeling the compiler on the structure on the original C interp. Yes, it is easy to seen how psyco can improve the running speed of the present C interpreter: _any_ compiling will do so! But with respect, I dispute the assertion that knowing actual values of operands is going to produce faster code that that produce by a decent C compiler applied to an _equivalent_ algorithm done in C. Please note: it is _precisely_ this extremely strong assertion that must be true for there to be any speedup gained in translating Python's C libraries into Python! We already have C libraries that work very well. I would be _very_ leery of messing with them... 5. Another way to see that psyco isn't really doing much is the following. Basically, psyco emits calls to the same runtime helpers that the C interpreter does. Yes, psyco may improve the calling sequences to these helpers, but it does not eliminate calls to those helpers. But a C compiler will never do worse that the code in the helpers, and will often do _much_ better. I challenge this group to provide even one example of Python code, for which psyco will emit better code than that produced by a C compiler on a transliteration of that code into C. I believe no such counter-example will ever be found. I am not much interested in anecdotal reports of Python being faster than C, and I would be happy to study in depth any purported counterexample. If you believe you have a real counterexample, please first make sure that the algorithms appear identical. Second, please try to make the counterexample as small as possible. If I am wrong, the counter-example should provide a _clear reason_ why all my arguments above are wrong. And wouldn't that be great :-) I believe the arguments given should be given greater weight than the "psyco has more knowledge" mantra. You want to convince me otherwise? Show me the code, or provide a _detailed_ explanation for how my arguments do not apply. Edward P.S. I trust that this group will interpret my remarks as constructive. I believe it is important at the beginning of any project to have proper goals and expectations. Make no mistake: I believe this project has the potential to be extremely valuable, even if my arguments are correct. And I would indeed be happy to be _proved_ wrong. However, I think it a dubious policy to assume that Python can outperform C, for several reasons: 1. There is no need to burden this project with unrealistic expectations. Python doesn't have to beat C for Python to rule the world! :-) 2. I am concerned that assuming that we can do the impossible will skew our efforts. Yes, by all means, experiment using Python! Using C to do experiments would not be too swift :-) But lets not spend a lot of time worrying about bootstrapping until we are _sure_ that we won't be doing the final version in C! 3. There may be another way to speed up Python, namely replace (parts of) the byte code with compiled code. Armin mentioned in his papers that some ways of doing so might produce code bloat. But is that the end of the story? I think not. The same tricks that psyco uses in the "dispatcher" might well be applied to intermix machine code with byte code. I wouldn't want to focus _only_ on the "psyco way (tm)" in this project. Compile-time optimizations deserve at least some considerations, IMO. EKR -------------------------------------------------------------------- Edward K. Ream email: edream(a)tds.net Leo: Literate Editor with Outlines Leo: http://personalpages.tds.net/~edream/front.html --------------------------------------------------------------------

5 6

Re: psyco in Python was: Minimal Python project
by Edward K. Ream 19 Jan '03

19 Jan '03

Somehow it seems like Michaels reply got to the mail server before my original message. Here it is again. My apologies if this is redundant: Hi Michael, I'm going to copy this to pypy-dev so that other people can see this discussion. > > > > I just don't see how to implement psyco in Python in a production > > > > package without using the C interpreter as a bootstrap! And yes, I > > > > suspect that a C language version of psyco will be faster than psyco > > > > in Python. > > > Even after you've run psyco over itself? > > > > Yes, maybe even then. C compilers should do better _on the same > > algorithm_ on hand-written code than can any GIT. > Weeeeellll, this is the thing that gets me jumping-up-and-down-excited > about things like psyco: pysco has MORE information than the C compiler to > work with: while the C compiler only knows the algorithm to run, psyco > knows both the algorithm *and the data it is to run on*. Obviously, this > approach only wins if what you do next resembles what you did last, but I > think CPU caches have proved there is some mileage in that idea :) I don't think CPU caches have much bearing on this discussion. Caches speed up frequently used values. The problems here are not the same. The more I study psyco, the more I am convinced that there is _no way_ that psyco will ever produce better code than a C compiler. In brief, my reasons are as follows: 1. psyco has, in fact, no better information than does a C compiler. Remember that the "values" that psyco specializes upon are in fact _interpreter_ vars, so knowing those values is equivalent to knowing the types of operands. This does indeed allow psyco to emit machine code that is better than the equivalent C interp generic code. In fact, though, most of what psyco is doing is quite routine: replacing bytecode by assembly language. This will speed up the code a _lot_, but it is doing just like a C compiler does. 2. I have looked again at the code generators of the optimizing C compiler I wrote about 10 years ago. I can find no instance where knowing the value of an operand, rather than just its type, would produce better code. Yes, my compiler did constant folding (which eliminates code rather than improves it), but I do not believe doing constant folding at runtime is going to improve matters much, and is in fact very likely to slow down the running times of typical programs, for reasons given below. 3. It's easy to get seduced by the "psyco has more knowledge" mantra. In fact, one mustn't lose track of the obstacles psyco faces in outperforming C compilers. First, and very important, everything that psyco does must be done at run time. This means that even very effective optimizations like peephole optimizations become dubious for psyco. Second, and also very important, is that fact that psyco (or rather the code that psyco produces) must determine whether the code that psyco has already produced is suitable for the task at hand. The "Structure of Psyco" paper says this: "Dispatching is the set of techniques used to store a trace of the compiled code buffers and _find if one already matches the current compiler state_" (emphasis mine) In other words, it's not enough to specialize code! Psyco must determine whether the types used to compile a function match the types presently given to psyco. This searching is done in the "compatible" routine, and no matter how it is done is _pure overhead_ compared to the code generated by a C compiler. As I see it, both these issues are "gotchas". Neither can be eliminated completely, and each introduces overhead that will make the code emitted by psyco clearly inferior to the code produced by any decent C compiler. In particular, the more psyco specializes on runtime values of operands the bigger the code bloat and the more severe the problem of finding out what already-compiled code to use. 4. I have seen _nothing_ in psyco's algorithms or the code emitted by psyco that leads me to believe that psyco is "doing enough work" to outperform a C compiler. When I was a mathematics graduate student 30 years ago one of my professors made the remark that a mathematician need to develop a feel for the level of work required to do a new proof. Deep insights are not going to come from elementary methods, and there is no use in using deep methods to prove elementary results. I believe the same kind of analysis can (and should!) be done here. Yes, psyco is clever. In some ways it is _very_ clever, especially the idea of modeling the compiler on the structure on the original C interp. Yes, it is easy to seen how psyco can improve the running speed of the present C interpreter: _any_ compiling will do so! But with respect, I dispute the assertion that knowing actual values of operands is going to produce faster code that that produce by a decent C compiler applied to an _equivalent_ algorithm done in C. Please note: it is _precisely_ this extremely strong assertion that must be true for there to be any speedup gained in translating Python's C libraries into Python! We already have C libraries that work very well. I would be _very_ leery of messing with them... 5. Another way to see that psyco isn't really doing much is the following. Basically, psyco emits calls to the same runtime helpers that the C interpreter does. Yes, psyco may improve the calling sequences to these helpers, but it does not eliminate calls to those helpers. But a C compiler will never do worse that the code in the helpers, and will often do _much_ better. I challenge this group to provide even one example of Python code, for which psyco will emit better code than that produced by a C compiler on a transliteration of that code into C. I believe no such counter-example will ever be found. I am not much interested in anecdotal reports of Python being faster than C, and I would be happy to study in depth any purported counterexample. If you believe you have a real counterexample, please first make sure that the algorithms appear identical. Second, please try to make the counterexample as small as possible. If I am wrong, the counter-example should provide a _clear reason_ why all my arguments above are wrong. And wouldn't that be great :-) I believe the arguments given should be given greater weight than the "psyco has more knowledge" mantra. You want to convince me otherwise? Show me the code, or provide a _detailed_ explanation for how my arguments do not apply. Edward P.S. I trust that this group will interpret my remarks as constructive. I believe it is important at the beginning of any project to have proper goals and expectations. Make no mistake: I believe this project has the potential to be extremely valuable, even if my arguments are correct. And I would indeed be happy to be _proved_ wrong. However, I think it a dubious policy to assume that Python can outperform C, for several reasons: 1. There is no need to burden this project with unrealistic expectations. Python doesn't have to beat C for Python to rule the world! :-) 2. I am concerned that assuming that we can do the impossible will skew our efforts. Yes, by all means, experiment using Python! Using C to do experiments would not be too swift :-) But lets not spend a lot of time worrying about bootstrapping until we are _sure_ that we won't be doing the final version in C! 3. There may be another way to speed up Python, namely replace (parts of) the byte code with compiled code. Armin mentioned in his papers that some ways of doing so might produce code bloat. But is that the end of the story? I think not. The same tricks that psyco uses in the "dispatcher" might well be applied to intermix machine code with byte code. I wouldn't want to focus _only_ on the "psyco way (tm)" in this project. Compile-time optimizations deserve at least some considerations, IMO. EKR -------------------------------------------------------------------- Edward K. Ream email: edream(a)tds.net Leo: Literate Editor with Outlines Leo: http://personalpages.tds.net/~edream/front.html --------------------------------------------------------------------

3 3

Re: [pypy-dev] Re: psyco in Python was: Minimal Python project
by logistix 19 Jan '03

19 Jan '03

> If I am wrong, the counter-example should provide a _clear reason_ why all > my arguments above are wrong. And wouldn't that be great :-) I believe the > arguments given should be given greater weight than the "psyco has more > knowledge" mantra. You want to convince me otherwise? Show me the code, or > provide a _detailed_ explanation for how my arguments do not apply. > > Edward > Firstly, C compilation is static. Secondly, python can do plenty of stuff that can't be easily transliterated into C. I doubt any current C compilers would be able to optimize a C version of the following code (regardless of the practicality of it)... PythonWin 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on win32. Portions Copyright 1994-2001 Mark Hammond (mhammond(a)skippinet.com.au) - see 'Help/About PythonWin' for further copyright information. >>> def crazyRPC_getAge(username): .. """ .. Pretend this is a real RPC call, .. and a black box to the compiler. .. """ .. if username == "Bob": .. return 23 #int .. elif username == "Doug": .. return 12.5 #float .. else: .. raise Exception("Unknown user %s" % username) .. >>> def drinkingAge(age): .. def test(): .. return age >= 21 .. return test .. >>> bobCanDrink = drinkingAge(crazyRPC_getAge("Bob")) #returns function optimized for ints >>> bobCanDrink() 1 >>> dougCanDrink = drinkingAge(crazyRPC_getAge("Doug")) #returns function optimized for floats >>> dougCanDrink() 0 >>>

1 0

What do we know for sure?
by Edward K. Ream 18 Jan '03

18 Jan '03

At the start of any experimental project I think it is a good idea to catalog what it is that we know for sure. This is a "dangerous" list because mistakes here might close off promising avenues. Still, here is what I think we can say for sure about minimalPython/psyco: 1. It is clearly possible to generate code using a git that will execute faster than the equivalent code in the C interpreter. 2. Some kinds of code can be generated without knowing the types of _any_ operands. At least part of the flow of control code falls under this heading. Therefore, it _might_ be possible to move some of what psyco does to "compile" time. 3. Python is a dynamic language. Therefore, a big challenge is to know when to use already compiled code. Does anyone have anything they would like to add to this list? Does anyone dispute what I have said? Any corrections would be most helpful. Thanks, Edward -------------------------------------------------------------------- Edward K. Ream email: edream(a)tds.net Leo: Literate Editor with Outlines Leo: http://personalpages.tds.net/~edream/front.html --------------------------------------------------------------------

3 2

Lessons From (Limited) Experience
by roccomoretti＠netscape.net 18 Jan '03

18 Jan '03

I like the idea. In fact, after reading the psyco website, I started something like it myself in October. The answer to the question that is on everybody's minds? PyPython. (I envisioned it as potentially being the springboard for other versions: AdaPython, LispPython, etc.) Additionally, the goal was to make a clear and readable implementation of Python which people could study and play with, without requiring them to know C. My plan was "simply" to take the CPython code and convert it into Python code, minimizing the use of "high level" features like lambda, generators, etc., so that a small core could easily be hand compiled into the language du jour. Eventually, a reduced dialect of Python might be employed for the core (interpreter loop and basic objects) such that a simple compiler could be built for it. My greatest ally was my biggest enemy. To make things easier in development, I used close association of my program with the host system. This way I could defer converting the compiler and core objects untill later. Unfortunately, it was *extremely* unclear where PyPython ended and the host system began. In my final incarnation, the PyPython objects with external visibility were referenced from a global definition file (a'la python.h), where they were simply imported wholesale from __builtins__. But the problem which stymied me was the issue of what to do with Exceptions. I discarded the concept of copying the "return Null" technique of CPython - having to check every return value for an error condition seems so unpythonic. But raising native exceptions has the complication of discriminating between exceptions in the host system (or rather the PyPython code) and the end user interpreted code. I might have been able to do something with it if I could have created my own traceback objects from within Python. (That was my greatest frustration - the inability to create and modify core objects [frame, thread, traceback, etc.] from within python itself.) That's where I left it in December when I stopped for Christmas. (Don't bother to ask for code: most of what I wrote was dead ends or "mindless conversion" from C.) I agree with using cross compilers in the bootstrap proceedure and with being "stackless" - two features I was going to apply. One additional thing that came about as a direct result of Python's lack of a switch statement: I replaced the switch statement with an array of references to functions implementing the opcodes. (I was going for clarity over speed) One offshoot of this is the potential to have multiple opcode schemes in the same interpreter. (Like Python 1.5.2 and Python 2.2 - or better yet, Python and Java) How does that work with parameter/return value passing and potential psyco optimization? Don't know - didn't get that far. I might not make the sprint, but I'd be glad to help as I can, Rocco Moretti P.S. I would advise for some brave soul (more reliable than me) to start summaries of pypy-dev, like has been done recently for python-dev. It would be nice to have a record of all the major design considerations in a location which doesn't require several hours of sorting through fluff. __________________________________________________________________ The NEW Netscape 7.0 browser is now available. Upgrade now! http://channels.netscape.com/ns/browsers/download.jsp Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/

3 3

relevant reading
by Samuele Pedroni 18 Jan '03

18 Jan '03

Optimizing Dynamically-Typed Object-Oriented Languages With Polymorphic Inline Caches (1991) Urs Hölzle, Craig Chambers, David Ungar http://citeseer.nj.nec.com/hlzle91optimizing.html regards.

1 0