[pypy-dev] [pypy-commit] pypy dynamic-specialized-tuple: kill an assert that doesn't hold now.

[Alex Gaynor]

On Fri, Mar 30, 2012 at 9:15 AM, Hakan Ardo <hakan at debian.org> wrote:

> On Fri, Mar 30, 2012 at 2:49 PM, Alex Gaynor <alex.gaynor at gmail.com>
> wrote:
> > I'm a bit concerned that this branch may be breaking too many
> assumptions in
> > the JIT with the current approach.  The idea of this branch is to
> > dynamically specialize the shape of a tuple's memory, to store unboxed
> > objects.  Based on the current approach (storing all data in an array of
> > integers) you get traces that look like:
> >
> > p0 = new(<untyped storage>)
> > setfield_gc(p0, ConstPtr("io"), <FieldDescr shape>)
> > setarrayitem_gc(p0, 0, i0, <ArrayDescr int>)
> > setarrayitem_gc(p0, 1, p1, <ArrayDescr ptr>)
> > finish(p0)
> >
> > This is a trace for allocating a tuple like (int1, ptr1) and returning
> it.
> >  Do you think a trace like this breaks too many assumptions in the JIT,
> and
> > if so, how can we go about making the JIT work with this.
>
> That part might be fine. In this case the descr depends is not realy
> changing it just depends on the constant index. The assert could
> probably be relaxed to allow that. But what would traces reading
> values from the tuple look like. In cases where the tuple may conatin
> different types or if the index is not constant? Say something like
> this:
>
> sa = 0
> a = (1, 2.0)
> while sa < 3000:
>    sa += a[0] + a[1]
>    if sa > 1500:
>        a = (a[1], a[0])
>
>
> --
> Håkan Ardö
>

My idea is approximately you promote the shape whenever the index of a read
is constant.  Otherwise you produce a read on the shape, and a guard about
the type.

Alex

-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20120330/c1c7f006/attachment.html>