Thanks for the reply. To be a little more specific, we have internally tens of thousands of Perl modules. Before running them in production: we profile these modules, pass them through a circular reference detector (code that intercepts all allocations, and at certain intervals walks over Perl's SVs, AVs, HVs), and try to do static analysis on them for security purposes (this doesn't work well with Perl unfortunately, due to dynamic typing).
In our setting, there isn't a single module that takes up 3 or 5% of CPU. Since we profile code on a regular basis, these offenders are easy to catch and fix. The problem is, we have more and more modules written every day, each taking, say, %0.01 of CPU time, but they add up to quite a lot. We also have a lot of code running in the same environment in C++ (they talk over XS), and recently a friend forwarded the following benchmarks: http://shootout.alioth.debian.org/debian/benchmark.php?test=nbody&lang=all (one sample test) http://shootout.alioth.debian.org/debian/benchmark.php?test=all&lang=java&lang2=perl Every language has its merits, and I know you can never do an apples to apples comparison. However, if we can get more performance out of Perl's VM, well, that would be great. In short, I just wondered if Perl/Parrot were on the benchmarks, around where it would be. Thanks, Ozgun. On Mar 12, 5:43 pm, [EMAIL PROTECTED] (Chromatic) wrote: > On Monday 12 March 2007 14:29, [EMAIL PROTECTED] wrote: > > I wish I had better news for you, but I'm not sure anyone can answer your > questions easily without a lot more information. > > > I'd like to get opinions from developers on this list. I'm looking > > into this system that executes massive amounts of Perl 5 code on a > > Perl 5.8 interpreter. The system burns tons of CPU while running Perl > > code, and I'm speculating on ways to improve our throughput (say, 50 > > billion inst per module -> 10 billion inst/modl) and latency (say, 2 > > sec/modl -> 0.5 secs/modl). > > For us, switching to another language would require considerable > > effort. I'm wondering, if we could compile Perl 5 source code into > > Parrot byte code and run it in Parrot's VM, would we see any > > performance benefit? Intuitively, running compiled code should go > > faster than interpreting it. > > That depends on what you mean by "compiled" and "interpreting". Parrot has to > interpret its byte code too, depending on what "interpret" means and Perl 5 > compiles source code into an op tree and walks that. > > Parrot does have a JIT that can turn certain types of operations into > platform-specific instructions, but there's a time and memory cost for doing > that as well, and it can benefit certain applications but not others. > > > In summary, my questions are: > > > (1) How much effort would it take to convert Perl 5 source to Parrot > > bytecode? > > A fair amount. A complete translation of Perl 5 syntax and semantics is a > complex project. A subset of Perl 5 could be much easier. > > > Is this even possible? > > Yes it is. > > > (2) How much performance benefit should I expect if I [could] compile > > and run Perl 5 source? > > That really depends on your program and what the overhead is. > > I *expect* Parrot has less overhead for most operations than Perl 5 does > because: > > *) Parrot bytecode has better potential cache characteristics than Perl 5 > optrees do > > *) Parrot doesn't pay the overhead of magic in Perl 5 (which complicates just > about every pp_code) > > *) Parrot uses registers, not stacks, so it avoids the overhead of stack > manipulation > > However, Parrot does lack some of the maturity of Perl 5, so it hasn't had as > many optimizations done. > > > (I read "Perl 6 and the Parrot VM", but couldn't find any numbers or > > even performance speculations. I also looked into "The case for > > virtual register machines", but the paper examines the Java VM. Java's > > developer library cites an increase of 10x going from interpreted to > > compiled, but I don't know if that applies to dynamically typed > > languages.) > > The terms "interpreted" and "compiled" really need disambiguation in these > circumstances anyway; they're awfully fuzzy terms. > > -- c
