For Python, it can create a pre-compiled version file.pyc so that the program can be run without interpreted again. Can Ruby, PHP, and Perl do that same on the command line?
views:
885answers:
12Not for PHP, although most PHP setups incorporate a Bytecode Cache that will cache the compiled bytecode so that next time the script runs, the compiled version is run. This speeds up execution considerably.
There's no way I'm aware of to actually get at the bytecode through the command line.
Perl 5 can dump the bytecodes to disk, but it is buggy and nasty. Perl 6 has a very clean method of creating bytecode executables that Parrot can run.
Perl's just-in-time compilation is fast enough that this doesn't matter in most circumstances. One place where it does matter is in a CGI environment which is what mod_perl is for.
For Perl you can try using B::Bytecode and perlcc. However, both of these are highly experimental. And Perl 6 is coming out soon (theoretically) and will be on Parrot and will use a different bytecode and so all of this will be somewhat moot then.
According to the third edition of Programming Perl, it is possible to approximate this in some experimental ways.
Ruby 1.8 doesn't actually use bytecode at all (even internally), so there is no pre-compilation step.
If you use Zend Guard on your PHP scripts, it essentially precompiles the scripts to byte-code, which can then be run by the PHP engine if the Zend Optimizer extension is loaded.
So, yes, Zend Guard/Optimizer permits pre-compiled PHP scripts to be used.
For PHP, the Phalanger Project compiles down to .Net assemblies. I'm not sure if thats what you were looking for though.
For hysterical raisins, Perl 5 looks for .pmc
files ahead of .pm
files when searching for module. These files could contain bytecode, though Perl doesn't write bytecode out by default (unlike Python).
Module::Compile (or: what's this PMC thingy?) goes into some more depth about this obscure feature. They're not frequently used, but...
The clever folks who wrote Module::Compile take advantage of this, to pre-compile Perl code into... well, it's still Perl, but it's preprocessed.
Among other benefits, this speeds up loading time and makes debugging easier when using source filters (Perl code modifying Perl source code before being loaded by the interpreter).
There is no portable bytecode specification for Ruby, and thus also no standard way to load precompiled bytecode archives. However, almost all Ruby implementations use some kind of bytecode or intcode format, and several of them can dump and reload bytecode archives.
YARV always compiles to bytecode before executing the code, however that is usually only done in memory. There are ways to dump out the bytecode to disk. At the moment, there is no way to read it back in, however. This will change in the future: work is underway on a bytecode verifier for YARV, and once that is done, bytecode can safely be loaded into the VM, without fear of corruption. Also, the JRuby developers have indicated that they are willing to implement a YARV VM emulator inside JRuby, once the YARV bytecode format and verifier are stabilized, so that you could load YARV bytecode into JRuby. (Note that this version is obsolete.)
Rubinius also always compiles to bytecode, and it has a format for compiled files (.rbc
files, analogous to JVM .class
files) and there is talk about a bytecode archive format (.rba
files, analogous to JVM .jar
files). There is a chance that Rubinius might implement a YARV emulator, if deploying apps as YARV bytecode ever becomes popular. Also, the JRuby developers have indicated that they are willing to implement a Rubinius bytecode emulator inside JRuby, if Rubinius bytecode becomes a popular way of deploying Ruby apps. (Note that this version is obsolete.)
XRuby is a pure compiler, it compiles Ruby sourcecode straight to JVM bytecode (.class
files). You can deploy these .class
files just like any other Java application.
JRuby started out as an interpreter, but it has both a JIT compiler and an AOT compiler (jrubyc
) that can compile Ruby sourcecode to JVM bytecode (.class
files). Also, work is underway to create a new compiler that can compile (type-annotated) Ruby code to JVM bytecode that actually looks like a Java class and can be used from Java code without barriers.
Ruby.NET is a pure compiler that compiles Ruby sourcecode to CIL bytecode (PE .dll
or .exe
files). You can deploy these just like any other CLI application.
IronRuby also compiles to CIL bytecode, but typically does this in-memory. However, you can pass commandline switches to it, so it dumps the .dll
and .exe
files out to disk. Once you have those, they can be deployed normally.
BlueRuby automatically pre-parses Ruby sourcecode into BRIL (BlueRuby Intermediate Language), which is basically a serialized parsetree. (See Blue Ruby - A Ruby VM in SAP ABAP(PDF) for details.)
I think (but I am definitely not sure) that there is a way to get Cardinal to dump out Parrot bytecode archives. (Actually, Cardinal only compiles to PAST, and then Parrot takes over, so it would be Parrot's job to dump and load bytecode archives.)
here are some example magic words for the command-line
perl -MO=Bytecode,-H,-o"Module.pm"c "Module.pm"