develooper Front page | perl.perl5.porters | Postings from November 2017

Re: Porting/bench -- utf8 to code point speed up

Thread Previous
Karl Williamson
November 1, 2017 05:00
Re: Porting/bench -- utf8 to code point speed up
Message ID:
On 10/31/2017 05:47 AM, Dave Mitchell wrote:
> So I think the conclusion is that trying to second-guess the CPU is
> probably a waste of time!

You might be interested in the branchless decoder then,

It was faster than the dfa under some circumstances, but not in all.  He 
prefers the dfa to his own, in part because it avoids branches by 
requiring every input string to be padded with 3 trailing bytes.  Since 
I first looked at it, a link at the bottom has been added to a SIMD 
decoder, which works faster on some architectures, slower on other.
>> The total size of ./perl increased 100K bytes.  There were 98 calls in it
>> that got inlined; only 6 needed the full generality.
> Hmmm, that seems a bit excessive. I would be tempted to see what
> performance drop you get by not inlining the function, or only inlining
> it in a few critical places, or (if technically feasible) only inlining
> a smaller subset of the function.

>> I have pushed the branch as
>> in case anyone wants to look at it.
> It looks good, except I don't like the 'real' function being named the
> same as the inline function but with an extra _ prefix. It confused me a
> lot trying to review the diff. Maybe rename the 'real' function to
> Perl_utf8n_to_uvchr_full() (non-API but exported)?

I wondered about that name, so certainly I will take your advice.
>> If we did go with this, I don't know how it would work with the license,
>> which reads:
> IANAL but I can't see any reason not to include it the way you have.

It took me a bit to figure out this acronym, but it makes sense given 
their reputation.

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