Front page | perl.perl5.porters |
Postings from September 2002
On Mon, Sep 30, 2002 at 08:58:21AM +0200, Slaven Rezic wrote: > > Perl is a JIT compiler, it just doesn't store the resulting bytecode. > > perlcc and the B::Bytecode module can do that if you like, but I think > > Malcolm found that the time spend loading in the saved bytecode actually > > takes more time than just letting Perl recompile the original code. > > It's not translating to byte code, it's translating to native machine > code. Just looked at the code of the kaffe jit compiler: when > translating a method, then some (or all) instructions are translated > to assembler code. What it translates the code into is just an implementation issue. A JIT is simply something which takes human generated code (such as Perl or Java) and compiles it into machine readable code (such as Perl bytecode or Java bytecode or C code which is then translated into assembly then machine code or direct to assembly) and runs the resulting code in one step. The perl interpreter is such a beast. So are ruby and python. Dynamic languages make everything very grey. A JIT is a much more clear-cut in the Java world because they actually have seperate compile (javac) and run (java) steps. So the Java JIT is a physically seperate thing and its big deal for them because they didn't have one for so long. Having two steps to run a program is so 1980. ;) Just another one of those "We've been doing it for years but because Java does it everyone sits up and notices" things. If you want to translate Perl into machine code which can be saved, perlcc already does this via the B::C and B::CC modules. It was found to not be a significant win because all it does is translate the Perl code into a bunch of C code which calls Perl op functions which has already been translated into native machine code via a C compiler. And that's basically what perl already does. Plus you have to leave all of the perl interpreter in the resulting executable so things like require(), do() and eval() still work. You wind up with a rather large, unportable (and currently buggy) C executable that doesn't win you much run-time performance. About the only advantage is you can ship a single executable program to people that might not have a Perl interpreter. If you can write something which translates Perl code into more optimized assembly code, you may as well just stick that into perl itself and avoid a middle-man. The only way you can win is by having a compiler which does extensive, expensive examination of the Perl code and attempts to reduce the complexity of the Perl code itself, unrolling loops, inlining subroutine calls, removing unnecessary context changes, etc... Perl, since it must compile fast, doesn't optimize as much as it could. These extra optimizations can be done without too much hassle via the optimizer.pm module. optimize::int is an example, I believe. -- Michael G. Schwern <schwern@pobox.com> http://www.pobox.com/~schwern/ Perl Quality Assurance <perl-qa@perl.org> Kwalitee Is Job One I know you get this a lot, but you're breathtaking, like a vision of simplicityThread Previous | Thread Next