Larry Wall <[EMAIL PROTECTED]> wrote: > On Sat, Apr 16, 2005 at 10:36:37AM +0200, Leopold Toetsch wrote:
>: Above are only the PMC variants. There are optimized forms for array and >: hash lookup by native types: >: >: Px = Py[Iz] >: Px = Py[Sz] > Is there a bitarray lookup by native int? Yes. All array lookups support a native int index. >: But with PMCs we seem to have a bunch of different key-ish PMCs, >: including a BigInt PMC for bitarrays. > I don't mind the general MMDish cases, as long as they don't get > in the way of a writing a devilish fast LINPACK in Perl 6 without > too many contortions. And we can certainly contort Perl 6 to our > hearts' content, but I'm just trying to figure out whether ordinary > arrays default to shape(int) or shape(Int). My gut feeling is that > defaulting to shape(int) is going to buy the optimizer something, but > it's just that, a gut feeling. A default of shape(int) sounds very reasonable. WRT speed: we'll have basically two different runoptions similar to -Os and -Ot. The former is useful in cases, where 300 users are running "parrot order.pbc" (Dan Sugalski). The bytecode is read-only and can be shared via e.g. mmap(2). The latter can rewrite the bytecode and even inline the array access for the native integer case. > Yes, but there's still got to be some internal overhead in deciding > whether the run-time Int object is representing the integer in some > kind of extended bigint form. (Or are you meaning Int as Parrot's > native integer there?) A Parrot Integer PMC (32bit for a 32bit sytem), which has a different type number then a BigInt PMC. > ... Plus if you're optimizing based on run-time > typing, there has to be some check somewhere to see if you're > assumptions are violated so you can pessimize. The check is rather cheap. Given the (hypothetical) opcode: circumfix .MMD_GET_KEYED, Par, Pidx, Pdest $1 $2 $3 $4 it can be recompiled to: cache = $1 if ($2.type << 16 | $3.type) == cache.type $4 = (cache.function)(INTERP, $2, $3) else // consider some more cache slots else // MMD lookup There is one cache entry per bytecode location with this opcode (PIC, Polymorphic Inline Cache). The fast path is usually hit in more then 95% of the cases states the literature. With readonly-bytecode a slightly slower variant is the default, where the cache lookup involves some more indirections. > ... That sort of check > can be factored out to some extent, but not to the same extent that a > compiler can factor it out with sufficient advance type information, > either direct or inferred. (At least, that's my assumption. I don't > claim to up-to-date on the latest in optimizing run cores.) Type interference is a nice to have but difficult with dynamic languages. It needs support by the user (closed classes, no overloading) but yes, the compiler can emit a direct function call sometimes. > Larry leo