Front page | perl.perl5.porters |
Postings from January 2013
Re: use of LIKELY() and UNLIKELY() branch predictors
Thread Previous
|
Thread Next
From:
bulk88
Date:
January 31, 2013 19:13
Subject:
Re: use of LIKELY() and UNLIKELY() branch predictors
Message ID:
BLU0-SMTP72F6F1A6B2ACF502A5E2FDDF1D0@phx.gbl
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
>
> if (UNI_IS_INVARIANT(uv))
>
> 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.
Perl_hv_common
3 calls S_unpack_rec
pp_backtick
S_make_trie
S_find_byclass
S_scan_const
Perl_scan_num
S_swatch_get
Perl_upg_version
Perl_my_cxt_init
XS_DynaLoader_CLONE
pp_ssockopt
pp_getpeername
>
> 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.
svu_pv));
}
_____________________________________________________________
-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