|No such thing as a small change|
Re^8: Perl 5 Optimizing Compiler, Part 4: LLVM Backend?by dave_the_m (Prior)
|on Aug 29, 2012 at 14:34 UTC||Need Help??|
So, what you are saying is, if every XS-dabbling programmer, became an XS expert and learnt all the rules and tricks and techniques; and then they all modified all of their modules and programs, then things would run fasterNo. You were showing XS code that macro-expanded to very inefficient C, which you argued, might benefit greatly from LLVM being clever. Whereas I was in the main trying to point out that core perl code is nothing like that; it's been heavily worked on for years, the macro expansions are much better, etc, and the gains from LLVM are not nearly as clear-cut. (And you can get most of the gains on the 'bad' XS code just by using 5.14.0 or later, and using a non-threaded (or non-multiplicity) build.
Note also that LLVM is very unlikely to be able to able to optimise away any of the get_context() calls in the XS code.
Show me some actual assembly of a function in pp_hot.c that's being significantly crippled by the design of perl's macros, and I'll start to take it seriously.
Well, my current belief is that most important perl ops have tight code that are not hugely penalised by poor macros. If you believe differently, the onus is on you to identify such a function.
There's nothing particularly magical about pp_hot.c: it's just one file which contains the ops that people at some point in the past have speculated as being the the most critical, and gathered them together so that (a) they just might benefit from instruction cache hits; (b) alert people that if they mess with this code, they should be extra-specially careful not to make things go slower. Many of the OPs in the other pp*.c files are heavily worked too.
Speculation based on some two years (on and off) of looking at what LLVM can, and is, doing, but still speculation. And clearly labeled as such.
Well, my speculation, based on 11 years experience of working on the perl core, is that improvements with LLVM will come into the "10% better" category rather than the "5x better" or "perl runs at C speed" categories. Which is where this all started.
Don't get me wrong, I'm not opposed to things like LLVM; I just haven't been convinced yet that they can offer game-changing improvements.