Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much

Re^2: perllVm: A Linux test of how Perl and LLVM would work together.

by flexvault (Monsignor)
on Sep 08, 2012 at 17:38 UTC ( #992516=note: print w/replies, xml ) Need Help??

in reply to Re: perllVm: A Linux test of how Perl and LLVM would work together.
in thread perllVm: A Linux test of how Perl and LLVM would work together.


I have regenerated 'perllvm' a couple of times, the most recent with '-O3' for the compiler flags, and it seems to be about 15% faster on your code. I put a 'for (0..8)' around the actual calls, and it seems that improvement gets better for the first 4 iterations, but don't know if 'jit' is working or not. '-O3' had no effect for my testcase, but I think the I/O wouldn't change much.

perllvm -sw 3 9 4093 Took: 13.2621982097626 4093 Took: 12.8998439311981 4093 Took: 12.8468470573425 4093 Took: 12.8413920307159 4093 Took: 12.8571419715881 4093 Took: 12.8411600494385 4093 Took: 12.850515127182 4093 Took: 12.8421239757538 4093 Took: 12.8547790050507

When I ran with the 'gcc' Perl there wasn't any major changes for each loop. I think 15% shouldn't be ignored by just compiling with 'clang' and '-O3'. I joined the LLVM developers list, and hope they are patient :-)


"Well done is better than well said." - Benjamin Franklin

  • Comment on Re^2: perllVm: A Linux test of how Perl and LLVM would work together.
  • Download Code

Replies are listed 'Best First'.
Re^3: perllVm: A Linux test of how Perl and LLVM would work together.
by chromatic (Archbishop) on Sep 08, 2012 at 19:14 UTC
    ... but don't know if 'jit' is working or not.

    If I understand what you did, it's not, and it's not going to work. You compiled Perl 5 as a C program with a C compiler (clang) to a native binary, and you used that to run Perl 5 code as Perl 5 code.

    Unless I missed a flag somewhere that used clang to compile Perl 5 into a native binary which is a thin shim around the LLVM JIT library and a bunch of bitcode that's the real output from the compiler, you're not going to get any LLVM JIT for the Perl 5 VM itself.

    You're definitely not going to JIT the Perl 5 code for the Ackermann function itself because nothing translates that to LLVM bitcode and feeds it to the LLVM JIT.

    I don't mean to keep ranting about this, but it seems like a lot of people think that LLVM is a magic wand you can wave over a program and magically get a JIT and concomitant orders of magnitude performance improvements. clang is a C compiler, like gcc. If you use clang like gcc, you get the same kind of thing you'll get from gcc.

    By no means should anyone sneer at a few percentage points improvement from clang optimizations versus gcc optimizations, especially LTO, but you're not getting orders of magnitude improvement without a lot more work.


      The current documentation for LLVM has an example of using JIT with an existing 'C' program, without a custom front-end. I couldn't get it to work using the sample, so maybe it's not in version 3.1 - 3.2. And maybe it's a mis-print!

      I joined the LLVMdev list and asked that question.

      If and when I get an answer, I'll post either 'success' or 'failure' or whatever, but 15% improvement is nice. I'm not endorsing anything, since this is more of a learning exercise for me.

      IBM 'xlc' is way faster on p-series machines than 'GCC', but I gave up long ago trying to get 'C' code that was designed and tested with 'GCC' to get compiled with 'xlc'! If it's my code, then I'll go with 'xlc'.

      To generate a Perl 5.16.0 took half the time with 'clang' as it was to generate it with 'GCC'. And 100% of the Perl test-cases worked.

      For that, I'm impressed.

      Thank you

      "Well done is better than well said." - Benjamin Franklin

        Clang brings meaningful competition to free compilers and vastly improved diagnostics. Double yay. But chromatic's right. JITting Perl is a big big big job. If you'd done it, we'd be having this conversation many months later and you'd have been asking p5p a hard question every day.

            -- Chip Salzenberg, Free-Floating Agent of Chaos

        The current documentation for LLVM has an example of using JIT with an existing 'C' program, without a custom front-end.

        The Ackermann function, written in Perl 5, isn't a C program.

      chromatic, a few percentage points improvement from clang optimizations versus gcc optimizations

      I re-read your post, and just to clarify what I was talking about.

      The 15% improvement was comparing the original Perl5.16.0 compiled with '-O2' and the new Perl5.16.0 (perllvm) compiled with '-O3', and not the incremental re-running of the script.

      • 'GCC' '-O2' was 'perl5.16.0 -sw 3 9' -> Took: 15.2425358295441
      • 'clang' '-O3' was 'perllvm -sw 3 9' -> Took: 13.2621982097626
      And by dividing the 'GCC' time by 'clang' time, I got 1.149.

      But now I realized I compared '-O2' to '-O3' ( which could be the cause of any increase). So I went back and compiled 'GCC' with '-O3', but the Perl 'Configure' changed it to '-O2', so I couldn't compare apples to apples anyway. 'Configure' did allow the '-O3' with 'clang' but not with 'GCC'.

      I looked at the 'Configure' and it would have to change to add the 'jit' parameters as well, but until I get some feedback from the LLVM developers, it would be a waste of time.


      "Well done is better than well said." - Benjamin Franklin

Re^3: perllVm: A Linux test of how Perl and LLVM would work together.
by BrowserUk (Pope) on Sep 08, 2012 at 20:52 UTC

    flexvault. Whilst 15% probably equals as much as p5p have succeeded in clawing back since 5.6.1, if that is all that is available, then the additional complexity of adding LLVM toolchain and its dependencies to the mix isn't worth it for your average perl user and certainly not for p5p -- given the possibilities of per platform problems with the switch from gcc to llvm.

    For example, I've spent the week getting changes made to the llvm emitter, to fix up incompatibilities between its .o representation and the MS 64-bit ABI. (To their credit, once I'd figured out the right approach and danced their tune by fulfilling their SOP, they had a patch which fixed the problem within a couple of hours. They are a very impressive bunch of developers and nice guys to boot.)

    I've also had my work cut out tracking down a stack dump in their front-end. The source turn out to be a (known) bug in the 64-bit version of the MS STL. But the most impressive bit of the experience, is that the stack trace that the debug version of their tool-set produced when the problem (an assertion failure inside the STL) occured, led me directly to the line&offset in the LLVM source where the problem arose. For now, a hand-coded function substituted for the failing STL routine gets me moving along.

    But using LLVM as an alternative C compiler was never going to be enough to warrant the effort. For a start, you do not get JIT from llvm without making changes to the project (Perl) code-base.

    For JIT to work, you have to:

    1. link the LLVM JIT engine into the Perl binary.
    2. convert the perl program being run into LLVM IR at runtime and feed it to that engine.

    That is not a transparent -- compile with llvm and get JIT -- automated procedure. It requires (possibly substantial) changes to the perl sources. This is why I isolated the sources required to build the perl executable binaries from the rest of the perl infrastructure.

    The (my) idea is to have a process that takes a new perl distribution, sucks out the smallest number of files possible from it, applies LLVM to them and builds versions of perl.exe perl516.dll/.so that they inter-operate with the rest of the standard perl distribution; .pms, XS an'all.

    Of course, that breaks the next time p5p break binary compatibility -- about once every 3 days lately -- but if enough gains can be demonstrated in this way -- I don't yet know how much that would need to be? 200%? -- then it might then encourage dialogue, even active participation.

    But if not, for those people for whom this is important, the extra work of installing LLVM and a process to produce this alternative binary compatible "fast Perl" would be worth it. (And, for windows at least, making that alternative binary available as a 'plug-in' to a standard binary distribution can make it available more widely.)

    And if it meant trailing the latest version of perl, and only catching up every 2 or 3 or 5, p5p distributions, that would be okay. There has been very little new that I've missed since the addition of defined-OR in 5.10; and quite a lot -- like smart-matching, use Switch; those funny arrays as hashes that came and went; etc. -- that I've actively avoided from the get-go, that are now deprecated or seem likely to disappear before too soon. (I don't even use 'say' because they screwed up the implementation and -l is just easier to turn on and off.)

    As I've been saying from the start of this, I don't think that LLVM as an 'alternative C compiler' alone is ever going to produce viable benefits for the masses. The addition of llvm JIT to perl will require a substantial effort that will include (amongst other things) the splitting of the perl5x.dll into 2 or 3 seperate binaries such that the 'immutable' bits of perl -- those that define Perl -- can remain unchanged, whilst the potentially mutable bits -- the compiled representation and the runloop -- become accessible.

    I also think that there is substantial potential in using the LLVM tool-sets profiling and tracing capabilities to 'zoom in' on particular areas of the perl code-base and highlight source-level changes that could be applied (by p5p), to good effect for the entire Perl community.

    It is most interesting to go through the exercise of compiling selected pieces of perl source to LLVM IR and then back to C. The results are, as machine generated source code is apt to be, pretty unreadable. but by looking at small pieces in isolation and comparing it back to the input, it is possible to see the potential of small changes in the existing sources that could have substantial affects.

    An old adage goes: a job started is a job half done; and another that says: the first step is the hardest. And yet another: there is a time when the talking must stop.

    As a first step, the ability to get 15% (and substantially faster build times if my experience is anything to go by), for nothing more than using a different compiler is nothing to be sneezed at.

    But it is only the first step. The potential is all in what comes next -- and that is only limited by the imaginations of the doers, not the nay-sayers.

    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.

    RIP Neil Armstrong



      The documentation code to take and and apply LLVM to a 'C' source that I referred to:

      'llvm-config --cppflags --ldflags --libs core jit native -O3'
      This was used against a .c file to add 'jit'. It also is in the 'new' for version 3.1

      My interest is if it improves current Perl5 runtimes by xx%, then the additional work to 'improve' the Perl5 sources is even more justified.


      "Well done is better than well said." - Benjamin Franklin

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://992516]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others romping around the Monastery: (6)
As of 2018-06-23 11:01 GMT
Find Nodes?
    Voting Booth?
    Should cpanminus be part of the standard Perl release?

    Results (125 votes). Check out past polls.