allbery@ncoast.UUCP (Brandon S. Allbery) (02/28/88)
Now that I have perl running on ncoast (!@#$%&* compiler bugs! It may get
tossed in favor of gcc as soon as *that* leaves beta testing!) I have only
one complaint: compiling a perl script usually takes longer than running it.
I would like to suggest, therefore, that a "compile mode" be added to perl
which saves the compiled program to a file, and that such saved files be loaded
directly for speed. I haven't looked at it, so I hope it isn't like awk's
vaunted compile mode (write everything from &end to sbrk(0) to a file) that
this would have to be done.
Larry -- how much of a problem would this be? (And did you get my bugfix?
You forgot to trap divide-by-zero, which is rather hard to debug in floating
point on ncoast.)
--
Brandon S. Allbery, moderator of comp.sources.misc
{well!hoptoad,uunet!hnsurg3,cbosgd,sun!mandrill}!ncoast!allberylwall@devvax.JPL.NASA.GOV (Larry Wall) (03/05/88)
In article <7440@ncoast.UUCP> allbery@ncoast.UUCP (Brandon S. Allbery) writes:
: Now that I have perl running on ncoast (!@#$%&* compiler bugs! It may get
: tossed in favor of gcc as soon as *that* leaves beta testing!) I have only
: one complaint: compiling a perl script usually takes longer than running it.
I never noticed a problem with that. Of course, I'm using a Vax 8600. :-)
: I would like to suggest, therefore, that a "compile mode" be added to perl
: which saves the compiled program to a file, and that such saved files be loaded
: directly for speed.
Depends on what you mean by "directly".
: I haven't looked at it, so I hope it isn't like awk's
: vaunted compile mode (write everything from &end to sbrk(0) to a file) that
: this would have to be done.
Well, there's various ways you can do this, all with their various tradeoffs.
1) Do an abort() after compilation and then run a utility which turns
a core dump into an executable. Advantages: very fast, and you always
know you have all the functions you need, and in the version the script
was written for. Disadvantage: you carry a lot of excess baggage with
each compiled perl script--120 K on a Vax, 200 K on a Sun.
2) Do the awk trick. Advantages: still very fast, and you don't carry a
complete copy of perl around with every compiled script. Disadvantages:
you have to "recompile" every script if the interpreter changes
significantly. It's a kludge that probably won't work everywhere.
3) Write a code generator that spits out a C program which you link with
a perl library. Advantages: same as 1. Disadvantages: much slower
compile than 1, and you could end up linking in almost all of perl into
your script, which gives you the disadvantage of 1 also. It would
depend of course on the complexity of the script, but for example a
script that called "eval" would have to link in the whole bloomin'
parser.
4) Do a modified awk trick, in that any pointers are relativized upon
"compiling", and derelativized upon execution. Advantage: you could
probably get away with more modification to perl without needing to
"recompile" your scripts.
5) Another modified awk trick: keep, as part of the compiled script,
a copy of the original perl script, or a reference to it, and
recompile automatically if the perl version changes (or if the perl
script changes). Advantage: you don't need to worry about recompiling.
Disadvantage: some invokations of your script take much longer than
others.
6) Write a routine that dumps out the syntax tree like the dump routines
currently do if you say perl -D1024, and then write some routines to
read the syntax tree back in. You'd also probably have to dump the
symbol table. Advantages: probably faster than compiling a perl script
(though if the size of the info increases much over the size of the perl
script you can find your performance dominated by I/O costs). Also
would probably be compatible with new versions of perl. Disadvantages:
Not nearly as fast as whomping in a memory dump, since you have to
do all the mallocs again.
7) Compile to some other internal form than a syntax tree which can be
allocated in one hunk--maybe something like threaded code. Advantages:
might execute faster than current perl. Could probably be made version
independent, at the cost of a little relocation overhead on startup.
Disadvantage: I don't have time to rewrite the run-time system.
No doubt there are other ways. What do you other folks think?
: Larry -- how much of a problem would this be? (And did you get my bugfix?
: You forgot to trap divide-by-zero, which is rather hard to debug in floating
: point on ncoast.)
Yes, that was fixed in a recent patch.
Well, gotta run. I'm not going to have a whole lot of time this next month,
so don't expect the patches to come out as fast. I don't even have time to ack
messages properly, alas. I try, but if the first shot bounces, I give up.
If you find a bad bug and it isn't fixed within a month, then I probably didn't
get your original message. On the other hand, if it IS a bad bug, somebody else
has already told me, so no problem, eh? :-)
Larry Wall
lwall@jpl-devvax.jpl.nasa.gov