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

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

Thread Previous | Thread Next
From:
Steffen Mueller
Date:
January 31, 2013 12:51
Subject:
Re: use of LIKELY() and UNLIKELY() branch predictors
Message ID:
510A68C3.7060601@steffen-mueller.net
On 01/31/2013 11:45 AM, Zefram wrote:
> Steffen Mueller wrote:
>> Is it a fair assumption to think that most characters we deal with
>> are < 0x80?
>
> Yes.  Not only is this mostly the case for users' textual data, it's
> especially the case for machine-readable data, seen in all sorts of
> file formats and APIs.  The latter, in particular, are liable to be
> performance-critical.
>
>> Another fun one: What about UNI_SKIP?
>
> Each uv<0xwhatever is LIKELY.

I just pushed a branch smueller/likely that adds a bunch of LIKELY and 
UNLIKELY's. Not all of the type ux < 0x? yet, though.

>> Anything taint related could be considered unlikely. Another
>> judgement call: Do we want to slightly pessimize the already-slow
>> taint logic
>
> Yes.  Tainting is exceptional, and involves some explicit acceptance of
> a performance penalty.  We should minimise the cost of this feature to
> code that doesn't use it.  (In fact, a config option to omit the taint
> facility entirely would make sense, for the not-terribly-uncommon case
> of a performance-sensitive user compiling eir own perl.)

These are in the branch.

>> Would it be beneficial to add a separate function that only allocates
>> a new SV without checking whether we should reserve string space?
>
> Yes.  newSV() is a relic from very old Perl where strings made up a
> greater proportion of the data processed.  We can separate it into
> newSVnull() and newSVbuffer().  The former already has a mortalising
> counterpart in sv_newmortal().

Not in the branch.

> By the way, LIKELY() and UNLIKELY() should probably include an implicit
> cBOOL in their expansions.  As it is now, LIKELY(ptr) is saying that we
> expect the pointer to have the value 1, not merely that we expect it to
> be non-null.

Not in the branch either.

So far, my trivial and meaningless benchmarks have not uncovered any 
effect of the hints on linux/gcc4.7.2/x84_64. I did not look at the 
generated code.

--Steffen

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About