[pypy-dev] Fw: [pypy-svn] r13221 - in pypy/dist/pypy/rpython: . test

Armin Rigo arigo at tunes.org
Fri Jun 10 00:40:16 CEST 2005

Hi Ben,

On Thu, Jun 09, 2005 at 10:10:44AM +0100, Ben.Young at risk.sungard.com wrote:
> Looking at these commits, I just have a quick question. Can the ll_ 
> functions call each other?

Not right now, but of course it's clearly something that would be
useful.  We have an idea on how to enable it but it's not done yet.

> Also, does the bounds checking happen at this level, or at a lower one.

The bounds checking doesn't happen at all :-)  If we wanted to make them
we would have to write them at this level.  But the plan is to make sure
(by testing) that the source code of PyPy doesn't do out-of-bounds
accesses, and then just don't do the checks any more.  Well, I guess it
would actually be useful to have a "debug" flag around so that we can
enable or disable the bound checks...  (Note that a global variable
"debug=True" or "debug=False" that we test in the ll_ functions would do
the trick -- same as Eric's, in rint.py and rfloat.py, but tested from
inside the ll_ functions.)

> In a week or so I may have a little time to do a bit of coding. Is there 
> anything specific I should look at? For instance I noticed that at the 
> moment the list rep resizes exactly. The python version (and stuff like 
> std::vector in c++) have a overallocation stratagy thay minimises 
> allocation calls. Would this be an idea I could try to implement in 
> rpython?

An excellent question!  It's slightly strange, given that
pypy.objspace.std.listobject already does over-allocation, that we might
need it again at this lower level.  It's possible that it would make
sense for some of the lists that we have around, and not for others --
the hard question will eventually be to decide when to use it or not.
But yes, I guess that before deciding that, we'd need to have both
options written :-)  (There are still some open questions there; for
example, it's not too difficult to detect list comprehensions by looking
at the flow graphs; then instead of heuristic over-allocation for the
list that is being built, it's often possible to determine in advance
the size of the list -- e.g. because it will be the same length as
another list that we iterate over.)

Another direction we'll need soon: dictionaries -- we really need them
to translate PyPy, even in a limited fashion.  We don't use a lot of
dicts at all (there are 7 creation points in total in PyPy!), but well,
we need them still; these 7 uses are quite important ones.  They can be
divided in two categorizes: immutable prebuilt dictionaries that
basically use the key object's identity (i.e. whose keys have no __cmp__
or __eq__), and mutable dictionaries with string keys.  We'll probably
need two implementations, one for each case.  The str-keyed dict raises
all the usual questions: do we follow CPython's strategy and use a hash
table with interned strings?  Or do we use some other data structure?
(Note that app-level dicts don't use rdict; that's mainly for passing
keywords around and for the __dict__ of type objects.)

Finally, there is always the need for more low-level operations as well
as low-level versions of some builtins.  The rtyper is not complete as
long as the annotator supports more operations and built-in functions
than it (as seen in annotation.unaryop, annotation.binaryop and

A bientot,


More information about the Pypy-dev mailing list