develooper Front page | perl.perl5.porters | Postings from January 2013

Re: use of LIKELY() and UNLIKELY() branch predictors

Thread Previous | Thread Next
January 31, 2013 19:13
Re: use of LIKELY() and UNLIKELY() branch predictors
Message ID:
Steffen Mueller wrote:
> On 01/30/2013 07:33 PM, Dave Mitchell wrote:
>> Yeah. Just to be clear, I was pointing out the difficulties of automatic
>> profiling: I expect it would usually be obvious when to apply UNLIKELY 
>> etc
>> by hand.
> That's an interesting point of view. Many a potential big win would be 
> based on knowledge of relative frequency of occurrence of SV types. That 
> isn't at all obvious. Some things are: SvMAGICAL could almost always be 
> wrapped in UNLIKELY -- unless we're already in a branch that treats a 
> special case. This shows that those decisions are highly context 
> sensitive and thus aren't necessarily all that beginner-friendly.

How often is @ISA's magic run? Does utf8/swash loading use magic at all?

 > Furthermore for UTF8 handling,
> there's lots of loops over characters, checking
> which is:
> /* Is the representation of the Unicode code point 'c' the same 
> regardless of
>  * being encoded in UTF-8 or not? */
> #define UNI_IS_INVARIANT(c)        (((UV)c) <  0x80)
> Is it a fair assumption to think that most characters we deal with are < 
> 0x80? For the code I write, I'm pretty sure that yes, most characters 
> are UNI_IS_INVARIANT (yay, ASCII). But is it reasonable to discriminate 
> this way? If so, that could be a big win.

Someone's data could be 100% non latin 1. The whole world isn't written 
in latin script.

> There's easy cases, too: Anything that does if(...)croak() could be 
> considered unlikely because of the relative cost of exceptions.

Except for pp_die, I think the other croaks and panics can be 
deoptimized. I've slowly been doing that over time with the interp 
(nocontext croaks, wrappers around croak that add a common format 
string, so in the caller just 1 arg is put on C stack, not 2 or 3, etc).

> Finally, looking at what I think is a very hot function:
> SV *Perl_newSV(pTHX_ const STRLEN len)
> One could argue that if(len) should be unlikely.

Some (not all) len != 0 callers.
3 calls S_unpack_rec

> Would it be beneficial to add a separate function that only allocates a 
> new SV without checking whether we should reserve string space? It seems 
> to me like the majority of SVs aren't born as strings, so that could be 
> a similar change as SvREFCNT_dec_NN in that it saves one branch in very 
> hot code.

I dont think so, but what can be done is replacing the SvGROW with an 
absolute sv_grow (we know SvLEN will be 0 on a fresh SV and it is not a 
COW) and get rid of the sv_upgrade (grow will do an upgrade anyway). 
Preprocessed code ahead.
     if (len) {
         Perl_sv_upgrade(my_perl, sv, SVt_PV);
         (((sv)->sv_flags & 0x00010000)
          || ((XPV *) (sv)->sv_any)->xpv_len_u.xpvlenu_len < (len + 1) ? 
Perl_sv_grow(my_perl, sv,
               len +
               1) : ((sv)->sv_u.
-O1 asm code looks like this for me
   if ( len )
     Perl_sv_upgrade(my_perl, sv, SVt_PV);
     if ( *((char *)(&sv->sv_flags) + 1) & 1 || 
sv->sv_any->xpv_len_u.xpvlenu_len < len + 1 )
       Perl_sv_grow(my_perl, sv, len + 1);

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About