develooper Front page | perl.bootstrap | Postings from July 2000

Bytecodes, parsetrees and compilers

From:
Marius Kjeldahl
Date:
July 20, 2000 13:45
Subject:
Bytecodes, parsetrees and compilers
Message ID:
397764D5.2658D98B@kjeldahl.net
After having used perl quite extensively for various projects, I thought
I would share a couple of thoughts on some of the ideas about bytecodes
and compilers.

First of all, I would prefer to have a possibility of store complete
executables in some sort of "precompiled" form (possibly as simple as
storing the whole parse-tree of a perl program [including modules] to a
file). My primary motive for doing this is ease of distribution. I know
some progress have been made with the B and compiler modules, but these
are no where near being usable for a large multi-file/module perl
project yet. Being able to create a file that a "normal" perl executable
could run (containing all modules), or possibly an executable which is
simply a perl executable together with the precompiled file is what I
need the most.

As for speed, perl in it's current state is no where near the speed of
simpler languages such as C with it's current generation of compilers,
and I doubt it will be in the near future. Instead of trying to make
perl superfast or have perl create native binaries, I would prefer to
simplify and improve the framework for writing native code in perl (the
xs mechanism).

During my time with perl, I have used it for writing pretty large
projects some of which require some decent execution times (I make
computer games, and have used perl for writing backgammon software that
and a complete multiplayer poker server). For the backgammon software,
part of it needed to find all legal moves which I implemented first in
perl, then in C++ . Finding the legal moves involves analyzing all
possible moves for a certain set of dice. In poker, you need to do the
same for finding the best hands of each player. These kinds of searches
involves deep levels of recursive calls, and pulling them out of perl
made them many orders of magnitudes faster. However, pulling them out of
perl and creating native code perl modules were fairly easy, so rather
than focusing on getting perl to run as fast as native code I would
focus on making it easy to distribute perl software (specially to users
who do not have a clue about getting and installing modules).

I guess a pvm with the possibility to store "vm binary code" would
satisfy most of what I have written (assuming the pvm can call some
native libraries as well).

Just my $.2

Marius Kjeldahl
marius@kjeldahl.net



nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About