Hi William,

On Fri, Jul 8, 2011 at 10:31 AM, William ML Leslie
<william.leslie....@gmail.com> wrote:
> On another note: what Alex talks about as being two different cases
> are just one with the small int optimisation - all references can be
> compared by value in the C backend with small ints enabled, if the
> object space doesn't provide alternative behaviour.

No, because e.g. of longs.  You don't have the same issue if you use
longs instead of ints in this particular example, but more generally
the issue exists too.

A first note is that it's impossible to satisfy all three of Alex's
criteria in general: we would like id(x) to be a unique word-sized
number determined only by the value of 'x', and different for every
value of 'x' and for every object of a different type too; but if the
possible 'x'es are all possible word-sized integers, then it's
impossible to satisfy this, just because there are too many of them.
The problem only gets "more impossible" if we include all long objects
in 'x'.

The problem is not new, it is just a bit more apparent.  For example,
already in pypy 1.5 we have:

>>>> a = A()
>>>> d = a.__dict__
>>>> s = 'foobar'
>>>> d[s] = 5
>>>> id(s)
163588812
>>>> id(d.keys()[0])
163609508
>>>> id(d.keys()[0])
163609520

I thought that there are also issues that would only show up with the
JIT, because of the _immutable_ flag on W_IntObject, but it seems that
I'm wrong.  I can only say that Psyco has such issues, but nobody
complained about them:

lst = []
def f(x):
    for _ in range(3): pass    # prevents inlining
    lst.append(x)
def g(n):
    for i in range(n):
        f(i); f(i)

With Psyco a call to g(5000) puts in 'lst' 10000 integer objects that
are mostly all distinct objects, although there should in theory be at
most 5000 distinct objects in there.  (PyPy is safe so far because the
call_assembler from g() to f() passes fully built W_IntObjects,
instead of just cpu-level words; but that may change if in the future
we add an optimization that knows how to generate a more efficient
call_assembler.)

I suppose that it's again a mixture of rules that are too vague and
complains "but it works on CPython!" that are now being voiced just
because the already-existing difference just became a bit more
apparent.  Sorry for the rant, I don't have an obvious solution :-)


A bientôt,

Armin.
_______________________________________________
pypy-dev mailing list
pypy-dev@python.org
http://mail.python.org/mailman/listinfo/pypy-dev

Reply via email to