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

... 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.

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

Replies are listed 'Best First'.
Re^4: perllVm: A Linux test of how Perl and LLVM would work together. by flexvault (Monsignor) on Sep 08, 2012 at 20:12 UTC
chromatic, 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	[reply]
Re^5: perllVm: A Linux test of how Perl and LLVM would work together. by chip (Curate) on Sep 08, 2012 at 21:05 UTC
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	[reply]
Re^5: perllVm: A Linux test of how Perl and LLVM would work together. by chromatic (Archbishop) on Sep 08, 2012 at 21:32 UTC
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.	[reply]
Re^6: perllVm: A Linux test of how Perl and LLVM would work together. by BrowserUk (Patriarch) on Sep 09, 2012 at 01:40 UTC
The Ackermann function, written in Perl 5, isn't a C program. No, but the perl that runs ack.pl is a c program. If you compile the perl sources to bitcode and run them with lli, then it can jit the perl runtime whilst it is running Ack.pl. That wasn't what flexvault was doing; and I'm not sure what performance would result; but when you're first playing with this stuff it is easy to get confused about what is happening during the different phases; and/or sucked in by what you read. Whilst lli is slow compared to native-compiled C; the relative effects of it using JIT on the bitcoded C, do give some indication of the possibilities of gains that are possible when running the native-compiled C -- iff you can get the optimiser to see all the relevant parts of the C-source concurrently. Easier said than done given perl's architecture; but that could change. 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	[reply]
Re^4: perllVm: A Linux test of how Perl and LLVM would work together. by flexvault (Monsignor) on Sep 09, 2012 at 15:24 UTC
chromatic, ...at 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 BrowserUK_991333.pl 3 9' -> Took: 15.2425358295441 'clang' '-O3' was 'perllvm -sw BrowserUK_991333.pl 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. Regards "Well done is better than well said." - Benjamin Franklin	[reply]


P is for Practical
	PerlMonks