I've re-ordered things because gmail's love of top posting confuses the flow of the narrative.
> 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). I don't think that you're going to get a 4 or 5 fold speedup on existing code by either re-writing the interpreter, or recompiling to different bytecode for a different VM. > > > 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. But the problem with trying to figure out any subset is that it's likely that an existing codebase uses rather more Perl than you might like. Particularly if it has dependencies off into CPAN. > > *) Parrot doesn't pay the overhead of magic in Perl 5 (which complicates > > just > > about every pp_code) But the problem is that to make a faithful translation of Perl 5 into anything else, requires that the behaviour of magic and overloading works properly. Perl 5 is tricky to convert to a form that it suitable for a JIT compiler to make headway on, because not only can any value be polymorphic (string or floating point or integer), it can also be tied or overloaded. So basically a JIT for regular (and therefore existing written) Perl 5 code would be stringing together calls to the existing Perl 5 ops (or code as flexible as them), rather than really converting to low level CPU instructions. Perl 6 has resolved part of this by defaulting variables no "not tied" - only variables that are explicity declared as such may hold tied values. It may well be possible to provide ways to annotate Perl 5 with things like "this is never tied" or even "this is an integer" but it won't help existing code without a massive review/annotation(/bug introduction) phase On Tue, Mar 13, 2007 at 10:28:59AM -0700, [EMAIL PROTECTED] wrote: > 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: It would seem that profiling the Perl interpreter (while it is running your code) might reveal more than profiling the code itself. I would have thought that an organisation large enough to be maintaining tens of thousands of modules would be able to justify the resources to do that, and hopefully then feed back any improvements to the core. > 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. JVMs such as Sun's have a whole team of full time engineers working on them. Perl (and Parrot) don't have anyone paid - it's all volunteers. In some ways it's surprising how well Perl is doing despite that. We've managed to find some ways to speed things up in 5.10, and those that I've been able to backport will be in 5.8.9, but it's really hard to a: Actually find a representitive benchmark for "Perl code" b: Find any way to make a measurable difference Mostly I've found ways to reduce the memory of core structures, but as these are necessarily binary incompatible they can't go back to 5.8.x Nicholas Clark
