From owner-freebsd-questions Mon Dec 18 19:59:07 1995 Return-Path: owner-questions Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id TAA17683 for questions-outgoing; Mon, 18 Dec 1995 19:59:07 -0800 (PST) Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id TAA17675 for ; Mon, 18 Dec 1995 19:59:00 -0800 (PST) Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id VAA25491; Mon, 18 Dec 1995 21:01:11 -0700 Date: Mon, 18 Dec 1995 21:01:11 -0700 From: Nate Williams Message-Id: <199512190401.VAA25491@rocky.sri.MT.net> To: Terry Lambert Cc: nate@rocky.sri.MT.net (Nate Williams), questions@FreeBSD.ORG Subject: Re: undump program In-Reply-To: <199512190240.TAA13367@phaeton.artisoft.com> References: <199512190117.SAA25218@rocky.sri.MT.net> <199512190240.TAA13367@phaeton.artisoft.com> Sender: owner-questions@FreeBSD.ORG Precedence: bulk > > 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