Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 18 Dec 1995 21:01:11 -0700
From:      Nate Williams <nate@rocky.sri.MT.net>
To:        Terry Lambert <terry@lambert.org>
Cc:        nate@rocky.sri.MT.net (Nate Williams), questions@FreeBSD.ORG
Subject:   Re: undump program
Message-ID:  <199512190401.VAA25491@rocky.sri.MT.net>
In-Reply-To: <199512190240.TAA13367@phaeton.artisoft.com>
References:  <199512190117.SAA25218@rocky.sri.MT.net> <199512190240.TAA13367@phaeton.artisoft.com>

next in thread | previous in thread | raw e-mail | index | archive | help
> > Actually, since perl 'pre-compiles' code ahead of time, you will end up
> > with the pre-compiled perl binary (in it's internal state), which is
> > *much* faster to run since none of the error/syntax checking is done,
> > plus you get the added benefit of not needing the perl binary on your
> > distributed system.  (However, this is a moot point for any FreeBSD 2.X
> > system which comes with perl pre-installed).
> 
> You mean that it does a token prepass and runs tokenized code instead
> of text.  The syntax checking is in the token prepass.  This is a
> textbook interpreter implementatrion.

It also optimizes the code as well, so it's not quite a interpreter nor
is it a compiled language.  But, it's still more like the former than
the latter though.

> It seems that what is missing is not an "undump", but a "bload/bsave"
> mechanism.

Perl doesn't have one, so it's a moot point.  It has undump, so that's
what is used.

> > > There is no significant advantage to this approach over restructuring
> > > your perl script based on splitting the precaclulation out to allow
> > > you to execute it only once and hard-code the results in the perl
> > > script.  The resulting "binary" will run at the same speed.
> > 
> > Wrong.
> 
> Wrong that "there is no advantage" or wrong that "the resulting 'binary'
> will run at the same speed?

The resulting binary will run faster than a perl + script.  The
resulting binary need never run through the syntax checker and
optimizer.

> If the second case, then you should arrange to dump the perl
> interpreter and the token image 10 or more times to get even more
> speed out of it.  8-).

Umm, once the syntax checking and optimizer is done, you can't optimize
it more.  Even with the implicit smiley it makes abosultely no sense.
Does that mean we should take the intermediate pass in gcc and re-run
the results back through the optimizer 10 times to see if they run
faster?


> > If I gave you an core/un-dumped perl program, you'd have almost as much
> > (possibly more) difficulty in trying to re-create it as you would trying
> > to re-create a C program from it's core image.
> 
> If I had sources to perl to determine the token values and memory
> management, I could get the information out.

In the same manner as you could re-create the 'C' code given the
original compiler sources and the resulting executable.



Nate



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199512190401.VAA25491>