in reply to
Re: Perl 5 Optimizing Compiler, Part 5: A Vague Outline Emerges
in thread Perl 5 Optimizing Compiler, Part 5: A Vague Outline Emerges
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.