On Fri, Mar 30, 2012 at 9:15 AM, Hakan Ardo <[email protected]> wrote:
> On Fri, Mar 30, 2012 at 2:49 PM, Alex Gaynor <[email protected]> > 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
_______________________________________________ pypy-dev mailing list [email protected] http://mail.python.org/mailman/listinfo/pypy-dev
