Leo --
Your concern about speed has been raised before, but I still don't see it
(one of the reasons I've been working on a toy VM to demonstrate is that I
figure there's some piece I'm not communicating well, and being able to
point at code would help). Optable build time is not a function of program
size, but rather of optable size, since it would be (at least
conventionally/normally) built as a sort of preamble in the generated
bytecode.
My latest thinking is to divorce the two issues: dynamic optables and
dynamic loading (of anything). In the past, I've considered both pieces
important (and I still think that), but now I think even if you statically
link all the ops, still doing dynamic optables is a win (and enables us to
implement dynamic loading of oplibs eventually).
I am not against having some oplibs (core) statically linked, so we are
not in disagreement there. Over the long haul, we might disagree as to
what constitutes a "core" op, but I don't think that bears on whether or
not dynamic optables are right for Parrot.
Having dynamic optables means that we do not require core.ops to ever
stabilize entirely. That will be handy for a while yet during development
(as you mention), and will remain handy as Parrot evolves through later
versions and we discover we wish we had op X but don't (something I think
you see as unlikely, but I see as likely). Dynamic optables essentially
reduce friction -- they give us the freedom to add ops however and
wherever we want without having to overcome a barrier created by a desire
to not obsolete people's existing PBC files.
I don't think it remains a problem how to run ops from different oplibs
_fast_. Op lookup is already fast (assuming it hasn't slowed significantly
from where I left it). Here is an email that mentions the original
switch() based find_op() oplookup performance being on a par with the
interpreter's ops/sec rating:
http://archive.develooper.com/perl6-internals@;perl.org/msg08629.html
So, that would mean that for the oplookup part, you would have the
equivalent of executing an extra N ops (remember that the mops.pasm idea
of "an op" is one of the fastest ops in the interpreter, too) *only at the
startup of your program*. There would be some additional cycles eaten to
do the optable build besides the oplookup, but I assume that the bits and
pieces of that are going to be fast, too, since it would likely leverage
other dynamic list code that has been optimized for speed. After the
preamble, while the program is running, the cost of having a dynamic
optable is absolutely *nil*, whether the ops in question were statically
or dynamically loaded (if you don't see that, then either I'm very wrong,
or I haven't given you the right mental picture of what I'm talking
about).
BTW, here's the email where I show the benchmarker I used to measure the
oplookup speed with the original switch() implementation of find_op(). It
looks up a single op numerous times. Of course, a better one would
randomly pick a known op name N times and look that up.
http://archive.develooper.com/perl6-internals@;perl.org/msg08676.html
Regards,
-- Gregor
Leopold Toetsch <[EMAIL PROTECTED]>
11/04/2002 05:40 AM
To: [EMAIL PROTECTED]
cc: Brent Dax <[EMAIL PROTECTED]>, "'Andy Dougherty'"
<[EMAIL PROTECTED]>, Josh Wilmes <[EMAIL PROTECTED]>, "'Perl6
Internals'" <[EMAIL PROTECTED]>
Subject: Re: Need for fingerprinting? [was: Re: What to do if
Digest::MD5 is
unavailable?]
[EMAIL PROTECTED] wrote:
> Leo --
> Here's one of the messages about how I'd like to see us link op
> implementations with their op codes:
>
> http://archive.develooper.com/perl6-internals@;perl.org/msg06193.html
Thanks for all these pointers.
I did read this thread WRT dynamic opcode loading. We will need a
possibility to load different oplibs. But for the core.ops I'd rather
stay with the static scheme used now.
Your proposal would solve the problem with fingerprinting, but
especially for huge programs, the loadtime overhead seems to big for me.
Invalid PBC files due to changes will get less and less, during
development of parrot, when the core.ops stabilizes.
Remaining is the problem, how to run ops from different oplibs _fast_.
leo
