Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister
 
PerlMonks  

Re^5: Perl 5 Optimizing Compiler, Part 4: LLVM Backend?

by BrowserUk (Patriarch)
on Aug 29, 2012 at 09:30 UTC ( [id://990416]=note: print w/replies, xml ) Need Help??


in reply to Re^4: Perl 5 Optimizing Compiler, Part 4: LLVM Backend?
in thread Perl 5 Optimizing Compiler, Part 4: LLVM Backend?

When in order to call this:

void _24to32( SV* packed ) { IS_VARS; char *pp = SvPVX( packed ); _4BY6 up; int i; IS_RESET; for( i=0; i<24; i+=3 ) { up.packed = _byteswap_ulong( *(unsigned long*)&pp[ i ] ); IS_PUSHUV( up.u.a ); IS_PUSHUV( up.u.b ); IS_PUSHUV( up.u.c ); IS_PUSHUV( up.u.d ); } IS_DONE; return; }

You have to go through this lot:

void XS_main__24to32(register PerlInterpreter* my_perl , CV* cv); void XS_main__24to32(register PerlInterpreter* my_perl , CV* cv) { extern int Perl___notused ; SV **sp = (*Perl_Istack_sp_ptr(((PerlI +nterpreter *)Perl_get_context()))); I32 ax = (*(*Perl_Imarkstack_ptr_ +ptr(((PerlInterpreter *)Perl_get_context())))--); register SV **mark += (*Perl_Istack_base_ptr(((PerlInterpreter *)Perl_get_context()))) + +ax++; I32 items = (I32)(sp - mark); #line 179 "_24to32.c" if (items != 1) Perl_croak_xs_usage(((PerlInterpreter *)Perl_get_context()), cv +,"packed"); ((void)ax); sp -= items; { SV * packed = (*Perl_Istack_base_ptr(((PerlInterpreter *)Perl_g +et_context())))[ax + (0)]; #line 117 "_24to32.xs" I32* temp; #line 188 "_24to32.c" #line 119 "_24to32.xs" temp = (*Perl_Imarkstack_ptr_ptr(((PerlInterpreter *)Perl_get_cont +ext())))++; _24to32(packed); if ((*Perl_Imarkstack_ptr_ptr(((PerlInterpreter *)Perl_get_context +()))) != temp) { (*Perl_Imarkstack_ptr_ptr(((PerlInterpreter *)Perl_get_context() +))) = temp; do { do { const IV tmpXSoff = (0); (*Perl_Istack_sp_ptr(((PerlIn +terpreter *)Perl_get_context()))) = (*Perl_Istack_base_ptr(((PerlInte +rpreter *)Perl_get_context()))) + ax + (tmpXSoff - 1); return; } whil +e (0); } while (0); } return; #line 199 "_24to32.c" (*Perl_Istack_sp_ptr(((PerlInterpreter *)Perl_get_context()))) = s +p; return; } }

and this lot:

void _24to32( SV* packed ) { SV **sp = (*Perl_Istack_sp_ptr(((PerlInterpreter *)Perl_get_contex +t()))); I32 ax = (*(*Perl_Imarkstack_ptr_ptr(((PerlInterpreter *)Perl +_get_context())))--); register SV **mark = (*Perl_Istack_base_ptr(((P +erlInterpreter *)Perl_get_context()))) + ax++; I32 items = (I32)(sp - + mark); char *pp = ((packed)->sv_u.svu_pv); _4BY6 up; int i; sp = mark; for( i=0; i<24; i+=3 ) { up.packed = _byteswap_ulong( *(unsigned long*)&pp[ i ] ); do { do { if ((*Perl_Istack_max_ptr(((PerlInterpreter *)Perl_g +et_context()))) - sp < (int)(1)) { sp = Perl_stack_grow(((PerlInterpr +eter *)Perl_get_context()), sp,sp,(int) (1)); } } while (0); (*++sp = + (Perl_sv_2mortal(((PerlInterpreter *)Perl_get_context()), Perl_newSV +uv(((PerlInterpreter *)Perl_get_context()), up.u.a)))); } while (0); do { do { if ((*Perl_Istack_max_ptr(((PerlInterpreter *)Perl_g +et_context()))) - sp < (int)(1)) { sp = Perl_stack_grow(((PerlInterpr +eter *)Perl_get_context()), sp,sp,(int) (1)); } } while (0); (*++sp = + (Perl_sv_2mortal(((PerlInterpreter *)Perl_get_context()), Perl_newSV +uv(((PerlInterpreter *)Perl_get_context()), up.u.b)))); } while (0); do { do { if ((*Perl_Istack_max_ptr(((PerlInterpreter *)Perl_g +et_context()))) - sp < (int)(1)) { sp = Perl_stack_grow(((PerlInterpr +eter *)Perl_get_context()), sp,sp,(int) (1)); } } while (0); (*++sp = + (Perl_sv_2mortal(((PerlInterpreter *)Perl_get_context()), Perl_newSV +uv(((PerlInterpreter *)Perl_get_context()), up.u.c)))); } while (0); do { do { if ((*Perl_Istack_max_ptr(((PerlInterpreter *)Perl_g +et_context()))) - sp < (int)(1)) { sp = Perl_stack_grow(((PerlInterpr +eter *)Perl_get_context()), sp,sp,(int) (1)); } } while (0); (*++sp = + (Perl_sv_2mortal(((PerlInterpreter *)Perl_get_context()), Perl_newSV +uv(((PerlInterpreter *)Perl_get_context()), up.u.d)))); } while (0); } (*Perl_Istack_sp_ptr(((PerlInterpreter *)Perl_get_context()))) = s +p; return; }

You really don't see any opportunities for some radical optimisations?

And remember, that is positively lightweight compared to the unoptimised C code produced for all of Perl's internal opcodes. Existing C compilers may be able to optimise some of that lot away on a function-by-function basis, but how much?

And now consider the possibilities of allowing the optimiser to look at *all* the internal functions and look for really radical optimisations?

Consider the possibilities of LTO and whole program analysis to lift whole chunks of that boiler plate above up to the runloop level on a per interpreter basis?

Then consider the possibilities of JIT noticing that the context doesn't (cannot) change across a whole swath of runtime code and reserving a register, say one of the unused segment registers, for it and using register relative addressing for each interpreter?

And then consider that LLVM doesn't have to follow C rules. It can invent weird stuff that C compilers (and C programmers) wouldn't even think of -- see my earlier example of it converting (at the IF level) an array of 52 shorts into a single 832-bit integer.

What might it do with the whole SVt_* type hierarchy? Imagine (for sake of totally speculative example) that it could reduce *all* the SV flag tests & sets to a single, simple bit manipulation at some calculated bit offset into a huge integer. Is that possible? Would it result in substantial savings if used uniformly throughout the code base?

Does any of this intrigue you? Even if only so that you can say: I told you so?


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

/div/div

Replies are listed 'Best First'.
Re^6: Perl 5 Optimizing Compiler, Part 4: LLVM Backend?
by dave_the_m (Monsignor) on Aug 29, 2012 at 12:24 UTC
    What you have shown is XS code compiled using the most inefficient, backwards-compatible mode.

    If you compile it with #define PERL_NO_GET_CONTEXT at the top of the file, you'll find that all those calls to Perl_get_context() are avoided. Similarly, using perl 5.14.0 or later removes all those Perl_Istack_base_ptr()-style function calls.

    All those checks on stack size could be replaced by using a single EXTEND(24) at the start of the function.

    All those calls to create mortals could be removed by returning an array rather than a list. Etc.

    A lot of the macros designed for use by XS are less efficient (depending on circumstances) than the macros use in the perl core, due to the need to ensure backwards compatibility, or to insulate the XS code from the internal details of the core etc.

    If you look at the actual code in the hot pp ops, you'll find its hardly unoptimised. And if a modern C compiler can't cope with a a few extra no-op {} scopes added by perl's macros, there's something wrong with it. 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.

    Other than that, everything you've talked about is wild speculation so far.

    Dave.

      What you have shown is XS code compiled using the most inefficient, backwards-compatible mode. If you compile it with ... All those checks ... All those calls ... macros designed for use by XS are less efficient ...

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

      Wouldn't it be nice if we had tools that took care of that?

      And if a modern C compiler can't cope with a a few extra no-op {} scopes added by perl's macros, there's something wrong with it.

      If C compilers were able to optimise away all that stuff, then wouldn't #define PERL_NO_GET_CONTEXT be unnecessary? An effective noop under optimisation?

      Compile-time optimisers cannot optimise across compile unit boundaries. C compilers are beginning to do LTO, but at a very limited level.

      If you used LLVM simply as an alternative C compiler, it couldn't do much more than modern C compilers do, but it is capable of doing so much more.

      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.

      You could show me ...

      But who decided what was "hot"? On the basis of tracing what code?

      If the functions in pp_hot.c have come in for some special attention that has proven demonstratively worth that effort, isn't it possible that programs that use function outside of pp_hot.c might benefit if the functions they use came in for similar treatment?

      And isn't it just possible that a radically different (un-C-like) alternative like LLVM might be able to make pp_hot.c type changes elsewhere, in an automated manner?

      And maybe even find other changes that C compilers and programmers wouldn't even consider?

      Other than that, everything you've talked about is wild speculation so far.

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

      And it will remain that way until someone tries it. (Aren't you in the least bit intrigued?)


      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

      p
        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 faster
        No. 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.

        You could show me ...

        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.

        Dave.

Re^6: Perl 5 Optimizing Compiler, Part 4: LLVM Backend?
by Will_the_Chill (Pilgrim) on Aug 29, 2012 at 10:30 UTC
    +1 Inspiring! XD

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://990416]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others about the Monastery: (7)
As of 2024-03-28 18:39 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found