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
