On Wed, Aug 27, 2003 at 02:27:51PM -0700, Deryk Barker wrote: > Thus spake Kirk Strauser (kirk@strauser.com): > > > At 2003-08-27T11:41:17Z, Pigeon <jah.pigeon@ukonline.co.uk> writes: > > > > > To me, it seems that the obvious solution is to run the script through a > > > Perl compiler, and produce a binary executable that should execute at the > > > same order of speed as any other compiled HLL code. > > > > Perl is compiled into opcodes before execution begins. All Perl is compiled. > > Perl is byte-compiled (like java was intended, like python) which > means that the resulting bytecode must still be interpreted, adding a > level of overhead to compilation to native code. > > python actually can be "frozen" to produce an executable that does not > require IIRC even the python runtime library to be present. Even "frozen" python needs to be interpreted. The only difference is that the interpreter is glued to the executabled (or possibly the necessary parts of the interpreter). This is because when you do c = a + b, in Python the types of a and b may have to be determined at runtime, so you need code to handle that. This really hurts you if you are adding two integers. Instead of compiling to something like: code to add two integers (possibly a single instruction) it compiles to: 1) code to determine type of a 2) code to determine type of b 3) break to code to add two integers Perl, python and java can all be "frozen". But in all 3 cases there is some level of overhead that is lost to such runtime "interpretation". With perl a perl interpreter is put into the executable making a huge executable. The other option is linking with a runtime library. I think gcc compiles java in the same way (I haven't seen any other ahead of time compilers for java). Bijan -- Bijan Soleymani <bijan@psq.com> http://www.crasseux.com
Attachment:
pgpaKcbp98DvS.pgp
Description: PGP signature