Re^2: Perl 5 Optimizing Compiler, Part 5: A Vague Outline Emerges

[bulk88]

Looking at the purely loop unrolling / stack side of things, I did a rough calculation to see what improvement could be expected. I ran the following perl code: $z = $x + $y * 3; ($x and $y contain ints) in a loop under cachegrind, and used the results to estimate approximately what proportion of the execution is spent on loop/stack overhead. The answer was approx 20%. Note that the example above was chosen specifically to use simple perl ops where the overhead is most likely to dominate. Perl has a lot of heavyweight ops like pp_match(), where the relative overhead is going to be much smaller. Also, the LLVM verison will have an overhead of its own for setting up args and the current op, just hopefully less than the current overhead. So that means that overall, the loop/stack stuff is going to give us something less than 20% speedup (and probably a lot less in practice, unless all your perl code does is lots of lightweight stuff like additions). Set against this there might be improvements from LLVM being able to compile the resulting code better, but my speculation is that it won't be significant.

You are comparing the legacy Perl 5's performance with legacy Perl 5. I dont think Will wants to just recompile Perl 5 the C program with Clang or write yet another B::C.

The third thing to do with LLVM, (which is what I think BrowserUK is advocating, but I may be wrong), is the wholesale replacement of perl's current runtime, making perl's parser convert the op tree to LLVM IR "bytecode", and thus making a perl a first-class Perl-to-LLVM compiler, in the same way that clang is a first-class C-to-LLVM compiler. This would be a massive undertaking, involving understanding all the subtleties and intricacies of 25,000 lines of pp_* functions, and writing code that will emit equivalent IR - even assuming that you kept the rest of perl the same (i.e. still used SVs, HVs, the context stack, pads etc).

Why keep the pp_* and SV/contexts/pads if they aren't needed? Some CVs can be determined to be optimizable by SCA in "LLVM Perl". If a CV can't be optimized (eval string exists), the CV stays as slow "legacy" CVs. Easy things get faster, hard things stay slow. The point is to optimize "typical" Perl code, not optimize the performance of JAPHs.

[dave_the_m]

You are comparing the legacy Perl 5's performance with legacy Perl 5. I dont think Will wants to just recompile Perl 5 the C program with Clang or write yet another B::C.

No, I am specifically trying to evaluate the effect of the "basic" Yuval approach of JIT converting a CV's ops tree into a list of calls to modified pp_* functions, that then get compiled to IR. That approach seemed to be what Will was advocating. Certainly it was the starting point for the LLVM discussion.

Dave