[pypy-dev] Re: [Python-Dev] AST branch update

[Neal Norwitz]

On 10/21/05, Armin Rigo <arigo at tunes.org> wrote:
> Hi Neal,
>
> (CC-ing to pypy-dev, if you don't mind :-)

Of course not!

> > Any interesting ideas that can be used to improve CPython?
>
> That's an interesting question.  So far PyPy has produced mostly bug
> reports for obscure errors and crashes in CPython -- only today, trying
> the CPython HEAD with the newly merged AST compiler showed 7 of them :-)

Jeez!  I was hoping that was in PyPy, but I see the bug report now. 
At least one was taken care of (lambda became <lambda> again).

I suspect there could be many more corner cases like these.  Thanks!

> Anyway, someone might want to try
> again to scrap Py_INCREF/DECREF and use the Boehm GC with CPython.

I would like to see this happen, but don't think I will have time for
it.  I hope to try to play with speeding up function calls.

> I suppose that we will soon try more experiments.  Coming to mind:
> unboxed integers to see if they help -- I doubt it, but if they have a
> large effect then CPython might consider to use them at least in some
> speed-critical places.  Different locking approaches for threads, though
> it is unclear how much of what we do there would be practical for
> CPython.  Several implementations for app-level string objects, e.g. a
> "string slice" one, a "lazily joined substrings" one, etc., which might
> give interesting speed-ups for some programs.

Yes, I think this is true.  I'm not sure it would be an overall win.  Another
possibility is for lists.  I wonder how many times empty lists are
instantiated, but never used.  It might be possible to make a sort of
copy-on-write empty list that is (are) cached.  Also, list slices are
often used for iteration.  It would be nice if we didn't need to make
a copy of the list.  This becomes difficult since the list could
change during iteration.  But we could make a copy in that case at the
time it was modified.  I'm not sure if that would be easy or difficult
to implement.

> All in all I suspect that it will be some more time before we can go
> past the current state, which is "being a bit like CPython but not quite
> as good".

Best of luck.

If anyone has time it wouldn't hurt to give little status updates on
python-dev from time to time, just so we have more insight into PyPy
and anything interesting you run across.  I don't know how the
experiment will turn out, but it's interesting to watch.  And you have
certainly contributed many bug reports on corner cases which helps
improve Python.

n