Geoffrey Broadwell wrote:
On Tue, 2009-03-24 at 11:56 -0500, Patrick R. Michaud wrote:
On Mon, Mar 16, 2009 at 09:41:37PM -0700, Geoffrey Broadwell wrote:
Gotcha. Sounds fine by me (as long as the Perl 6 signatures don't carry
significantly more overhead than the pure-PIR version).
They do carry more overhead (perhaps even a significant amount), but it's a
necessary overhead because we want them to properly participate in
multidispatch, and we'd like things like .signature to work properly.
I get the feeling that dispatch performance is going to be utterly
critical for Perl 6 (all implementations). It seems to me that in
gaining flexibility and orthogonality, we've lost a lot of places that
Perl 5 could special case things for speed.
Of course, Perl 6 allows us to optimize *different* things for speed --
hyperoperators come to mind -- but it's hard to let go of the things
that you already have, you know?
While performance now isn't that much of a priority for me right now,
having some concrete ideas about how to get it later is more of one. :-)
Dispatch performance will indeed matter heavily. In fact, one of the few
bits of performance-related work that has been done in Rakudo is in that
area: our MMD implementation has a cache. The Parrot one currently does
not, meaning that on the decision about what to call we might actually
get a small win moving things into setting.
However, anything we win there we lose overall because signature binding
is currently really quite unoptimized. So yes, moving things into the
setting will slow us down for now. But signature binding is going to be
an improvable hot-path further down the line (but it's not worth
spending time on now since it probably needs more changes yet, and
optimized code is harder to maintain and build on).
Further, because we have a much richer type system now, there's going to
be space for a bunch of type-based analysis. This I hope will not just
give more performance, but also detect more errors at compile time.
Another bonus in this area is that the language is designed so we can
know the set of candidates at compile time for things in our current and
outer scope, meaning we might even be able to skip multi-dispatch
entirely. (Note that even if you do a "use" which imports more stuff,
we'll still know about them, since that happens at compile time). The
whole area of type-driven optimization is something I really look
forward to working in - but it's secondary to a complete implementation
of the Perl 6 spec.
Anyway, the take away from this is: yes, I do expect we'll be able to
make this performant later and there have been choices in the language
design to aid this. However, it's too early to really dig into
optimization - not only because we should have a focus on
feature-completeness first, but also because we probably don't have
adequate test coverage yet to know when we've got an optimization and
when we've found a fast way to give the wrong answer. :-)
Jonathan
