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

[BrowserUk]

No, not in the slightest. I think this is the fundamental impedence mismatch between you and me on this subject.

Having spent the last 9 hours to produce what I posted, having you dismiss it in under 10 minutes -- barely enough time to read the post, never mind look at the code with any attention to detail -- is ... well ... let's just say, disappointing and leave it at that.

You keep asserting that if LLVM can only be given a full picture of the program, it will be able to do (unspecified) wonderful things with it.

Firstly, I said may, not "will". It is "(unspecified)" because -- as I've been at pains to state often & clearly -- noone yet knows. I've provided a long list of possibilities, cited documents with examples of them. But I am not a computer and cannot possibly be expected to mentally run hundreds of thousands of lines of Perl sources through a dozen or more optimisation techniques and pick out salient examples to satisfy your demands for the instant gratification of "a concrete example".

All I've sought from you, is your knowledge and expertise of and with the existing codebase, to enable the investigations to get a quick, clean start.

PS I completely fail to understand the the point of your showing how run.c gets converted to IR. run.c just contains a single trivial C function, operating on a few args and variables of particular types, and the IR knows the types of those args. So what?

The "what" is, that if it can encapsulate and annotate the entire internal (data) structure of Perl, in 100 lines of language independent, platform independent, eminently human readable, metadata, then it can also rewrite those structures and the function trees that use them in ways that neither a C compiler, nor a C programmer -- no matter how experienced -- could ever imagine doing.

[chromatic]

Yes, but Dave's point is that that's not the slow part of Perl 5. You either generate LLVM code specific to the semantic knowledge of Perl 5 programs or you precompile any Perl 5 program you want to optimize to bitcode and let LLVM do whole program analysis. In the latter case, you may be able to get more than 20% improvements if enough of your code stays in analyzable chunks and you can perform optimizations like dead code elimination and hoistings. In the former case, you have to tell LLVM about the semantics of the language because it can't infer them from a big wad of C code.

LLVM may be able to optimize the source code of the Perl 5 VM and that may be worthwhile, but that doesn't necessarily provide a measurable improvement to programs written in Perl 5.

(Let me belabor this point with what should be a really obvious example.)

Suppose I wrote a program that reads a multi-gigabyte file line by line to pick out a handful of records. No matter how much I microoptimize my code to get rid of dispatch overhead, I'm only going to get real speed benefits one of two ways: if I fix that algorithmic problem by hand, or if some very clever analysis of the code by something which understands the semantics of the code can rewrite it for me.

Unfortunately, LLVM doesn't understand the semantics of the Perl 5 language. That's why you either have to get the entire program into bitcode (so that it can infer what's going on at a level it does understand) or build up some sort of LLVM-aware VM that can map the semantics of the language to LLVM's intermediate form such that intelligent JITting is possible.

Unless you do one of those two things, your theoretical maximum improvements are in the "Hey, that's a nice improvement, but it doesn't transform things" arena. Maybe in certain cases people are willing to spend a couple of hours on a powerful machine to compile an important program to bitcode and then to native code, but I'm not sure that's the end goal here.

[BrowserUk]

Yes, but Dave's point is that that's not the slow part of Perl 5.

And my point is, that no one, not me, not you, and not Dave, can possibly know what is possible until we try it.

The point of the exercise -- without me having to complete the entire project, on my own, in 10 hours, to make the point -- was to show how effective LLVM is in capturing not just the C semantics of C code, but the meta semantics of both the code and the data structures it uses.

Hoping (in vain) that by doing so, Dave would see beyond the C semantics of the perl sources, and see the possibilities of re-writing -- in the Haskell compiler nomenclature, term re-writing sense -- those structures and functions in such a way as to allow optimisations that are simply inconceivable: at the C level; or through the blinkers of C semantics.

Maybe in certain cases people are willing to spend a couple of hours on a powerful machine to compile an important program to bitcode and then to native code, but I'm not sure that's the end goal here.

Firstly, LLVM takes about 2 minutes to process 30,000 lines of C to 300 lines of IR. It then takes another 2 minutes to convert that to compile-able, linkable C++.

I think that for many people -- including Will -- the ability to develop a perl program as an interpreted entity with all teh productivity etc. that we know and love, and then when it is fully tested and working, spend a "couple of hours" or even a couple of days, converting that (the Perl program, all its modules and dependencies; and perl itself), to a fully portable bitcode representation, that can then be compiled and linked, (per platform), to standalone executables that run faster and are resistant to casual manipulations, is exactly what they would like!

If some of those benefits could be had from running perl & LLVM together in some kind of hybrid mode, all the better.